00:00:00 --- log: started forth/19.02.16
00:19:07 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
00:23:31 --- quit: spestov (Ping timeout: 255 seconds)
00:36:06 --- quit: markweston (Remote host closed the connection)
00:46:33 --- join: xek (~xek@apn-31-0-23-81.dynamic.gprs.plus.pl) joined #forth
01:23:50 --- quit: ttmrichter (Ping timeout: 264 seconds)
01:24:05 --- join: ttmrichter (~ttmrichte@185.103.242.216) joined #forth
02:04:32 --- quit: ashirase (Ping timeout: 244 seconds)
02:08:26 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:20:10 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
02:21:16 <corecode> hi
02:24:41 --- quit: spestov (Ping timeout: 244 seconds)
03:14:50 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
03:22:10 --- quit: pierpal (Ping timeout: 246 seconds)
03:27:14 --- join: pierpal (~pierpal@host254-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth
03:56:54 --- nick: presi-den -> `presiden
04:20:52 --- join: spestov (~spestov@67.245.201.127) joined #forth
04:25:37 --- quit: spestov (Ping timeout: 255 seconds)
04:31:47 --- quit: dave0 (Quit: dave's not here)
04:34:20 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:35:19 --- quit: rdrop-exit (Quit: Lost terminal)
04:51:20 --- quit: xek (Ping timeout: 250 seconds)
05:11:36 --- join: tbemann (~androirc@mobile-166-175-191-9.mycingular.net) joined #forth
05:14:41 --- quit: FatalNIX (Changing host)
05:14:41 --- join: FatalNIX (~FatalNIX@unaffiliated/fatalnix) joined #forth
05:18:15 <presiden> proteusguy, intigruing. Is the type inferred or there's mechanism to declare the type?
05:19:30 <tbemann> types? forth? wut?
05:21:57 <tbemann> (type inference reminds me of Haskell and OCaml)
05:29:19 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
05:33:47 --- quit: spestov (Ping timeout: 244 seconds)
05:35:38 <the_cuckoo> proteusguy: also interested here - posted the code anywhere? :)
05:37:59 --- join: TCZ (~Johnnnyas@ip-91.246.66.12.skyware.pl) joined #forth
05:38:09 <TCZ> wow 76
05:42:34 * tbemann is interested in the part of the conversation he missed
05:47:50 <tbemann> now try waking up those people
05:51:32 --- join: xek (~xek@apn-31-0-23-81.dynamic.gprs.plus.pl) joined #forth
05:54:22 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
06:00:24 --- quit: tbemann (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
06:16:35 --- quit: TCZ (Quit: Leaving)
06:40:11 <proteusguy> presiden, type signatures are quite explicit. I'm only about done with the first whitepaper draft. I have some test code but nothing that implements the full thing. That effort will start in March and I hope I can make it open source from day 1.
06:41:18 <Zarutian> proteusguy: what do those type signatures do? check criterions at compile time or runtime?
06:43:19 <proteusguy> compile time. so far it looks like I can do it all at compile time for the type correctness checks.
06:44:13 <proteusguy> I've also got a concept of ontologies that will be built later that act sort of like an extended type system with a constraint solver. that's more blue sky and will come after the actor model aspects are implemented.
06:44:45 <proteusguy> when the initial draft of the white paper is ready I'll post a link here. should be a few days more.
06:45:13 <Zarutian> I assume that you have the usual datum datatypes around. But how do they compose into more abstract ones? what about pointer types?
06:45:35 <proteusguy> there are no pointers allowed in this one.
06:45:47 <Zarutian> references?
06:45:58 <KipIngram> Sp proteusguy, ok, so say I run a word.  How does the system know what's on the stack?
06:46:02 <proteusguy> probably the closest language for the initial type system is what you see in Elm.
06:46:07 <KipIngram> What the types are?
06:46:24 * Zarutian is betting on tag types in the values
06:46:32 <Zarutian> type tags*
06:46:53 <KipIngram> Well, that would just be merging the type stack into the data stack, then.
06:49:19 <proteusguy> here's how a fibonacci function/word would be implemented: https://bpaste.net/show/7bf5fdb098c5
06:52:11 <Zarutian> this looks just like a Haskel variant. That is like EBNF matching rules and what their results are if they match
06:52:12 <KipIngram> proteusguy: How is type information stored?
06:53:12 <proteusguy> Its definitely not Haskell - it's actually a practical language. ;-) But certainly Haskell did some of this stuff first.
06:53:45 <Zarutian> btw, what word is usually used to get next char in the source being evaluated?
06:54:37 <proteusguy> you guys are asking questions which are TBD as the specification is still incomplete. :-) But I hope to have answers for you by April.
06:55:16 <Zarutian> proteusguy: look at these questions as factors into the TBD determination and decission process
06:55:24 <KipIngram> Ok, but there will be an explicit representation of the type of each stack item *somewhere*, right?
06:55:55 <proteusguy> nope - doesn't look like it. i thought so initially then my test implementation didn't need it.
06:56:15 <KipIngram> I don't buy it.  Let's say you put some item of type X on the stack.
06:56:30 <KipIngram> Then you work for three weeks putting stuff on above that, working with it popping it etc.
06:56:33 <proteusguy> I've got more stuff going on than a normal forth. so it's not a fair comparison.
06:56:39 <KipIngram> All that time that first item's just riding at the bottom of the stack.
06:56:46 <KipIngram> Finally three weeks later you uncover it.
06:56:51 <KipIngram> What is its type and how do you know?
06:57:10 <KipIngram> How does the system know "X"?
06:57:24 <proteusguy> the type declaration is enforced at compile time. the compiler knows when it's assembling things. the type information is stored in the word dictionary. doesn't need to be on the stack at runtime.
06:57:40 <KipIngram> I'm talking about during interactive use.
06:57:57 <Zarutian> KipIngram: this is what I hate about 'type erasure' kind of thinking in design. My answer to that "if the type was erased then why the fuck does your system keep track of it in the first place?"
06:58:09 <proteusguy> not erasing anything.
06:58:26 <KipIngram> Oh, are you not storing the actual data on the stack, but rather a reference to the dictionary?
06:58:40 <proteusguy> anyway- I have to run home now. be back in a while.
06:58:48 <KipIngram> Like if you type 54, does it put 54 on the stack, or a pointer to some dictionary 54?
06:58:56 <proteusguy> KipIngram, when you refer to a word to be executed what do you put on the stack?
06:59:11 <proteusguy> it puts a 54.
06:59:43 <KipIngram> Well, the interpreter puts the xt of the word on the stack and then runs EXECUTE.
06:59:47 <KipIngram> Just like traditional systems.
06:59:58 <KipIngram> In my case the xt is the CFA.
07:00:10 <proteusguy> so if the type information is in the word definition why isn't that also adequate?
07:00:33 <KipIngram> In that case a specific compiled sequence of code is being executed, that always does the same thing.
07:00:54 <KipIngram> In the fully general system you have to account for the user doing random stuff while that data is buried down in the stack - there is no telling what he's going to do.
07:01:00 <KipIngram> It's not a fixed explicit set of actions.
07:01:02 <proteusguy> doing the same thing and returning the same type structure on the stack are not necessarily equivalent.
07:01:29 <proteusguy> KipIngram, strongly typed languages, such as Elm, do this all the time.
07:01:42 <KipIngram> Well, I don't want to argue on Saturday morning.  I'll wait and see.  But this feels like it can't work to me -- I'd like to be wrong.
07:01:46 <proteusguy> sorry gotta run for now. ttyl.
07:02:09 <KipIngram> Be safe.
07:02:13 <proteusguy> KipIngram, well neither of us are 100% convinced yet so you'll get no argument from me. just my experiments thus far are promising. :-)
07:02:48 --- quit: proteusguy (Quit: Leaving)
07:02:56 <KipIngram> Maybe he doesn't support overloaded words.
07:03:16 <KipIngram> That's part of the issue to - you want + to work on ints and floats, for example.
07:03:41 <KipIngram> In a normal Forth system you know that thing on top is a pair of ints BECAUSE YOU SAID "+".
07:03:55 <KipIngram> That's the only thing + takes, so either that's a pair of ints or  you made an error.
07:12:17 <KipIngram> You could argue that as far as *correct* (in the sense of what you actually accomplish) operation, Forth is typed and the type information resides in the user's brain.
07:12:58 <KipIngram> I know that's sort of an academic point, but still...
07:13:15 <KipIngram> If you're going to get useful results out of a system, types must be considered.
07:14:12 <KipIngram> Sometimes we say "Forth only keeps integers on the stack."
07:14:23 <KipIngram> But that's not true - you can WRITE a word that regards those bits as anything you want.
07:14:44 <KipIngram> Forth keeps chunks of bits on the stack, and most of its built-in words regard those chunks as integers.
07:15:12 <KipIngram> The data on the stack has no meaning at all, beyond the meaning ascribed to it by the executed words.
07:16:21 <KipIngram> For that matter, you can write a word that regards the top 10 elements on the stack as a single thing, so Forth doesn't really even "chunk" the data on the stack.  It's not even a stack except for the fact that the words treat it that way.
07:17:02 <KipIngram> It's convenient for us to think of it that way BECAUSE of the words that exist.
07:17:05 --- quit: spestov (Ping timeout: 245 seconds)
07:18:03 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth
07:18:03 --- mode: ChanServ set +v proteusguy
07:20:32 <proteusguy> ok back - anyway - I think it's better to understand what I'm doing and why I'm doing it before getting into the how I'm doing it bit. Hopefully have answers for the first two in a few days with the whitepaper.
07:21:56 <john_cephalopoda> KipIngram: ANS systems use a floating point stack, which is separate from the regular parameter stack. So + can not mean anything but "add those integers" because floats on the float stack are not affected by that word.
07:22:18 <john_cephalopoda> Otoh f+ only affects the float stack and won't modify the regular parameter stack in any way.
07:23:56 <corecode> reasonable choice
07:27:29 <john_cephalopoda> So some kind of typing on the stacks is present. If you save it to memory though, you'll have to remember what type you used.
07:30:43 <KipIngram> john_cephalopoda: Right.  One of my strong desires for the future is to have my system able to give me a Matlab/Octave type numerical computing environment (as an application - not in its base configuration).
07:31:08 <KipIngram> I *want* to be able to type integers, floats, one of each, vectors, matrices, etc. etc. - WHATEVER - and then say + or * and have it just do the right thing.
07:31:39 <KipIngram> ANS Forth expects me to do + when I want to add ints and F+ when I want to add flaots.  I want that application to be able to make such decisions for me.
07:32:22 <KipIngram> The way I see to do that is to have the type of the stack items avaialble at word search time, and the system will find the word of the given name that also is marked as taking the matching types.
07:33:12 <KipIngram> And since the word found in that process will not only CONSUME certain types but also PRODUCE certain types, the system can modify the type stack upon execution of that word so it's set for the next word search.
07:33:32 <KipIngram> When compiling, it won't modify the live type stack - it will modify a private copy of it it's using for the compile process.
07:33:39 <corecode> proteusguy: what are you doing?
07:33:52 <the_cuckoo> KipIngram: have also thought about that, but think it's a bit dangerous - what happens if you have a mix of types?
07:34:12 <KipIngram> What do you mean?  It would support a mix of types just fine, I think.
07:34:12 <proteusguy> corecode, building a forth-ish language that is strongly typed and implements an actor concurrency model.
07:34:19 <KipIngram> Give me an example of what you have in mind.
07:34:29 <corecode> proteusguy: runtime strict typing or compile time?
07:35:04 <the_cuckoo> KipIngram: i mean say you have <int> <float> [op] - would it gravitated to preserving the type of the first or the second? 
07:35:16 <proteusguy> corecode, compile time
07:35:20 <corecode> oh
07:35:24 <corecode> i'd be interested in this
07:35:32 <corecode> can you keep me in the loop?
07:35:37 <proteusguy> will be posting a white paper in under a week I hope.
07:36:08 <proteusguy> then a proper initial specification after that along with a canonical implementation and test suite.
07:36:12 <KipIngram> corecode: You sound like me - I'm pretty open to compile time "sophtication" but I want run time kept lean and sleek.
07:36:26 <corecode> run time is simple
07:36:29 <the_cuckoo> proteusguy: looks interesting to me - keep me in the loop too :)
07:36:33 <corecode> but by then what do you do?
07:36:43 <corecode> proteusguy: do you want to bounce ideas?
07:36:44 <proteusguy> KipIngram, yep - strong typing should actually allow things to run faster. more optimization options.
07:37:03 <proteusguy> corecode, I do - once I publish the white paper that documents my goals.
07:37:08 <corecode> ok
07:37:19 <KipIngram> Yes, me to proteusguy.  I don't mean to be coming off as critical - it's just that I've thought about this a lot and never saw a way around somehing LIKE a type stack, so if you've found a way then you've trumped me.  :-)
07:37:48 <corecode> i guess you need to formalize a calculus to be able to analyze stack effects
07:37:57 <KipIngram> proteusguy: And it would make preventing stack overflow and underflow simple as well.
07:38:17 <corecode> KipIngram: what are your ideas?
07:38:32 <proteusguy> KipIngram, depends on how much our requirements overlap. But yeah - I thought the same way as you when I started. I'm not 100% convinced I can get away with it but it looks promising thus far. I'm seeking out informed critiques so long as they are aligned with my objectives for the language.
07:39:20 <KipIngram> corecode: Just to add a stack that has the type of each data stack item in it.  When searching for a word, require that the top of the stack match the word's input arguments.
07:39:25 <corecode> KipIngram: did you envision a type signature?
07:39:28 <KipIngram> Then update that type stack as each word is interpreted.
07:39:36 <corecode> that's all runtime
07:39:41 <corecode> not compile time
07:39:46 <KipIngram> No, it's *interpret* time.
07:39:50 <proteusguy> corecode, did you see my basic code example? check out the bpaste I posted earlier.
07:39:56 <corecode> what does interpret time mean?
07:39:58 <KipIngram> If you compile a word, then when you execute that word nothing happens within the execution.
07:40:05 <corecode> proteusguy: no, sorry
07:40:07 <corecode> was out
07:40:20 <KipIngram> It's just when you find a word in the dictionary, the system will modify the type stack to reflect it's execution.
07:40:34 <proteusguy> corecode, https://bpaste.net/show/7bf5fdb098c5
07:40:34 <KipIngram> The internal execution of that word could take hours, and no diddling with the tpye stack will occur.
07:40:37 <corecode> KipIngram: i don't understand
07:40:47 <KipIngram> Ok, let me do an example.
07:40:47 <corecode> you search for words while compiling
07:41:00 <KipIngram> Let's say that I put a pair of floats on the stack.
07:41:03 <KipIngram> And then type +.
07:41:08 <corecode> in a word?
07:41:18 <KipIngram> No, just at the interpreter input line for now.
07:41:25 <corecode> ok
07:41:30 <KipIngram> So it finds the + that says it receives 2 floats.
07:41:34 <corecode> can you discuss it in the context of words?
07:41:44 <KipIngram> It ignores the + that takes 2 ints, because the types don't match.
07:42:09 <KipIngram> So it finds that float/float +, and the outer interpreter gets its xt on the stack and EXECUTEs it.
07:42:26 <KipIngram> And then the OUTER INTERPRETER removes to float items from the type stack and pushes one float item on.
07:42:40 <KipIngram> So that the type stack reflects that float/float + has just executed.
07:42:43 <corecode> ok
07:42:53 <KipIngram> But lets say I wrote that float/float + in Forth, as definitions.
07:42:54 <corecode> how wold that work in a compiled word?
07:42:59 <corecode> yes
07:43:01 <KipIngram> I wouldn't - it would be a primitive - but let's just say.
07:43:17 <KipIngram> While that Forth code implementing float/float + is executing, NOTHING is done to the type stack.
07:43:29 <KipIngram> The entire type stack delta of that compiled word gets handled by the outer interpreter after it's done executing.
07:43:44 <corecode> proteusguy: where does typing come in?
07:44:05 <KipIngram> So this whole thing is managed by the "interpret loop," using before and after type info in the definition headers.
07:44:08 <the_cuckoo> KipIngram: yeah - that's what i mean - you have to make a choice on behalf the user - which means they might not get the result they expect and would need to explicitly cast to enforce it - which basically is more verbose than just using a float or int specific word
07:44:13 <corecode> KipIngram: what's the goal?
07:44:23 <tabemann> back
07:44:26 <KipIngram> :-|  I'd think that should be clear at this point.
07:44:31 <tabemann> hey guys
07:44:40 <KipIngram> I'd also be able to do something like this:
07:44:43 <the_cuckoo> it is to me - and i agree it would be nice
07:44:56 <KipIngram> [ 1.7 4.3 2.8 ] [ 6.9 14.8 -7.3 ] +
07:45:01 <corecode> sounds like polymorphism
07:45:02 <KipIngram> And it would add those vectors.
07:45:11 <KipIngram> I think of it as operator overloading.
07:45:17 <corecode> yes, same thing
07:45:35 <KipIngram> That's the primary goal.
07:45:42 <corecode> yes, but what is the mechanism
07:45:47 <corecode> how do you compile this code
07:45:54 <KipIngram> I don't know how to explain it any better than I just did.
07:46:02 <corecode> you keep saying outer interpreter
07:46:04 <KipIngram> It basically compiles the same way it always does.
07:46:12 <KipIngram> The search process filters out the words that take the right type inputs.
07:46:22 <corecode> but let's say for a compute loop, there is no outer interpreter happening
07:46:24 <KipIngram> And the interpreter modifies the type stack accordingly as they execute.
07:46:43 <KipIngram> When compiling, a stack comment will give the before and after types.
07:46:54 <KipIngram> The compiler will initialize an internal type stack of its own to the input types.
07:47:03 <corecode> and based on this comment, you select the implementation?
07:47:06 <KipIngram> And as it compiles each component word it will modify that, and use THAT in the search process.
07:47:16 <corecode> aha!
07:47:18 <corecode> thanks
07:47:21 <tabemann> here's a question: how do you handle EXECUTE?
07:47:28 <corecode> now it is coming together
07:47:30 <KipIngram> Me?
07:47:33 <KipIngram> Same as always.
07:47:40 <KipIngram> The search process resulted in the XT of the right word.
07:47:44 <KipIngram> I EXECUTE it same as always.
07:48:01 <corecode> tabemann: it's not for type checking, it is for runtime dispatch
07:48:14 <corecode> i think tabemann means that EXECUTE is a black hole
07:48:21 <KipIngram> corecode: Ok, so I guess the missing piece was that the compiler would not use the live system type stack - it would use a copy based on what it got told that word received as input.
07:48:22 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
07:48:29 <corecode> it can do whatever to any of your stacks
07:48:39 <KipIngram> Oh, you mean if I ran execute live.
07:48:40 <tabemann> you can't statically determine the type signature of EXECUTE
07:48:42 <corecode> KipIngram: yes
07:48:42 <KipIngram> yes, that is an issue.
07:48:53 <corecode> execute is verboten
07:48:59 <KipIngram> I think there will be several places where "user intervention" would be required here.
07:49:07 <john_cephalopoda> Make variables two fields big.
07:49:07 <corecode> you can only use defer words
07:49:08 <KipIngram> If you do something behind the scenes, you'll have to tell the system you did that.
07:49:15 <john_cephalopoda> First field is the type, second one is the value.
07:49:28 <KipIngram> That's another reason not to try to put this into the base system.
07:49:30 <KipIngram> It has limitations.
07:49:31 <corecode> yea, i'm not excited about this
07:49:40 <corecode> i'd love to see it running
07:49:45 <KipIngram> But in a Matlab / Octave type system, you just wouldn't do those troublesome things.
07:49:54 <corecode> but i wouldn't want to use it
07:49:59 <corecode> feels unforthy
07:50:14 <KipIngram> I would only want to use it in certain situations.  Like when I wanted to do some numerical analysis.
07:50:21 <KipIngram> So it's an *app* - not a *system*.
07:50:28 <corecode> ok
07:51:11 <corecode> what i'd like to see is a way to lint the code and directly get errors if contracts are broken
07:51:33 <corecode> i guess you would write contracts in forth as well
07:51:52 <KipIngram> corecode: As I mentioned yesterday, I'm severely protective of Forth's run-time efficiency.  I won't even consider anything that would impact that.
07:52:21 * tabemann admits that hashforth is low
07:52:24 <tabemann> *slow
07:52:27 <corecode> you could do something like
07:52:28 <proteusguy> corecode, I have this plus also as you write your code you can see the stack signatures and notes on which items are modified, popped or pushed. 
07:52:30 <corecode> DISPATCH +
07:52:47 <KipIngram> proteusguy: Oh, that's pretty nice.
07:52:48 <corecode> to explicitly mark typed replacement
07:52:49 <KipIngram> You're right.
07:53:10 <KipIngram> I am planning a pretty intelligent code editor, so it could easily do that.  Based on cursor position.
07:53:14 <proteusguy> corecode, that's why my source example is quite vertically stacked... anticipating this helping feature side-by-side.
07:53:23 <KipIngram> Just put the cursor somewhere, and a status line would show you what the stack would look like at that point.
07:53:51 <corecode> proteusguy: how do you formulate contracts?  i can't make that out in your example
07:53:52 <KipIngram> I hadn't thought of that before, but I like it quite a lot.  :-)
07:54:27 <KipIngram> Another thing you could do, that I have thought of previously, is do an edit/compile time implementation of locals.
07:54:38 <KipIngram> Just inject a comment at any point:
07:54:55 <KipIngram> ...code... ( a b c) ... code2...
07:55:12 <KipIngram> And ...code2... could refer to a, b, and c, and the system would figure that out.
07:55:20 <corecode> not in a comment!
07:55:25 <corecode> comments are for comments
07:55:31 --- quit: xek (Ping timeout: 246 seconds)
07:55:31 <corecode> you can't put semantic stuff in there
07:55:32 <KipIngram> Well, in something comment-ish.
07:55:36 <corecode> {}
07:55:38 <KipIngram> Ok.
07:55:42 <tabemann> that's {}
07:55:45 <KipIngram> Fair enough.
07:55:58 <KipIngram> But anyway, the point is that it's an "aside."
07:56:02 <KipIngram> A notification to the compiler.
07:56:38 <KipIngram> I already have a set of words that let me fetch deeper into the stack than usual.  Or store, or +!, etc.
07:56:45 <KipIngram> 3@ fetches the 3rd item down.
07:56:47 <proteusguy> corecode, strictly based on type signatures.
07:56:54 <corecode> ah ok
07:57:06 <KipIngram> So that mechanism I just aluded to would replace the refernces to a/b/c with suitable ones of those.
07:57:10 <corecode> so you cannot formulate more complicated contracts
07:57:36 <proteusguy> corecode, if you've done much functional style programming you'd know that these can be extremely expressive contracts.
07:57:37 <KipIngram> And again, would be an edit time thing only  - the compiled code would just be the 3@ or whatever words.
07:57:54 <KipIngram> And I'd have the ability in the editor to switch that "rendering" on and off.
07:58:11 <corecode> proteusguy: yes, especially if you have an expressive type system
07:58:33 <corecode> proteusguy: but that also means that you build a parallel declarative language
07:58:37 * proteusguy is trying to keep it as simple as possible because the implementation needs to be understandable to system developers.
07:59:04 <proteusguy> corecode, it is indeed declarative - but it ain't parallel. that's inherent in the language.
07:59:14 <corecode> that's where c++ programmers get declarative template knots in their brains
07:59:26 <corecode> yes, but it is a different language
07:59:29 <proteusguy> corecode, haha guilty!
07:59:47 <corecode> yes, you can say "oh this is part of the overall language"
08:00:18 <corecode> but to me, template metaprogramming is a completely different language than OO/imperative real C++ code
08:00:48 <corecode> forth has this nice property that the system is the compiler is the language, so everything is done in the same way
08:01:26 <proteusguy> corecode, ActorForth continues this tradition. It's as much as system as it is a language.
08:02:14 <corecode> so could you use something other than ->, say -const->
08:02:18 <corecode> and define this yourself
08:02:27 <corecode> which then does something like -> does?
08:03:00 <proteusguy> you could but that's probably not the right approach or necessary. anyway we'll see.
08:03:05 <corecode> ok
08:22:24 <the_cuckoo> well, now i have my core system working, i'm looking into using it for robots - have a working build on a raspberry pi to play around with and extend :)
08:31:02 --- quit: tabemann (Ping timeout: 264 seconds)
08:49:46 --- quit: spestov (Ping timeout: 246 seconds)
08:54:08 <john_cephalopoda> Nice
08:55:32 <corecode> the_cuckoo: did you write your own forth kernel?
09:25:03 <crc> good afternoon
09:25:26 <rain1> hello crcr
09:40:27 --- quit: gravicappa (Ping timeout: 258 seconds)
09:48:03 <the_cuckoo> corecode: not really - it's a c++ lib which provides a forth-like interface/dictionary by way of an api and is very much interpreted - as a result, it's got some overhead
09:50:48 <the_cuckoo> main thing for me is that it it's very easy to expose c++ functions/objects/methods through it - once invoked those run as fast as they do natively
09:51:04 <the_cuckoo> (on account of them being native of course :))
09:53:03 * the_cuckoo does have a wacky idea about implementing a vm with pcode in the lib, but for that, i'll probably have to break with my current 'header only lib' approach
10:00:46 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
10:33:29 --- quit: spestov (Ping timeout: 246 seconds)
11:24:45 --- join: gravicappa (~gravicapp@h109-187-236-118.dyn.bashtel.ru) joined #forth
12:07:16 --- join: xek (~xek@apn-31-0-23-81.dynamic.gprs.plus.pl) joined #forth
12:28:52 --- quit: gravicappa (Ping timeout: 246 seconds)
12:30:57 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
12:54:43 <WilhelmVonWeiner> Hey guys, what kind of discussion did I miss? Been to London past couple days
13:00:43 --- quit: pierpal (Read error: Connection reset by peer)
13:04:01 --- quit: spestov (Ping timeout: 255 seconds)
13:20:50 --- join: tabemann (~travisb@50-247-156-97-static.hfc.comcastbusiness.net) joined #forth
13:22:01 <tabemann> hey guys
13:27:01 <WilhelmVonWeiner> hiya tabemann 
13:27:47 <tabemann> I'm busy adding comments to my VM assembly
13:28:06 <tabemann> it's gonna take a while, since there's a good amount of it
13:30:42 <rain1> Can you help me think of a name for a subroutine? it does a lookup & adds the item if not there
13:30:54 <WilhelmVonWeiner> @?+
13:31:03 <WilhelmVonWeiner> fetch-or-add
13:31:10 <WilhelmVonWeiner> fetch-insert
13:31:43 <rain1> thanks
13:32:14 <john_cephalopoda> insert-if-missing
13:32:27 <john_cephalopoda> Hm, but the "fetch" part is missing.
13:32:32 <WilhelmVonWeiner> doesn't provide the knowledge it fetches
13:32:34 <WilhelmVonWeiner> yea
13:37:58 <rain1> I'm thinking about doing a forth project where i copy jonesforth except using gforth assembler instead of gcc assembler
13:38:00 <rain1> what do you think?
13:40:12 <WilhelmVonWeiner> interesting learning experience
13:44:43 <rain1> actually, would you recommend another forth which has a x64 assembler?
13:45:12 <C-Keen> it doesn't really matter
13:56:11 <WilhelmVonWeiner> No I would not
13:56:17 <WilhelmVonWeiner> I think lina forth does assembler
13:56:22 <WilhelmVonWeiner> that's the forth I recommend
13:56:33 <WilhelmVonWeiner> but I don't have an opinion on it
13:57:12 <C-Keen> lina forth is nice
13:57:46 <WilhelmVonWeiner> Van der Horst is a really great programmer.
13:58:23 <rain1> http://subvert-the-dominant-paradigm.net/blog/?p=54 would it be better to use indirect threading than direct threading for 64bit?
14:16:02 <corecode> rain1: on intel?
14:17:36 --- quit: xek (Ping timeout: 258 seconds)
14:21:30 <corecode> rain1: did you have a look at my simple forth? i'd love to hear some feedback https://github.com/corecode/forth/blob/master/x86.fs
15:01:07 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
15:34:19 --- quit: spestov (Ping timeout: 255 seconds)
15:52:20 --- quit: tabemann (Ping timeout: 246 seconds)
16:27:29 --- join: tabemann (~travisb@50-247-156-97-static.hfc.comcastbusiness.net) joined #forth
16:34:42 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
16:38:45 <rdrop-exit> Good morning Forthwrights :)
16:43:14 --- quit: john_cephalopoda (Ping timeout: 252 seconds)
16:45:12 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:07:40 <crc> hi rdrop-exit 
17:07:56 <rdrop-exit> Hi crc
17:15:41 <rdrop-exit> Trying to kickstart Sunday morning with some espresso. Full day ahead.
17:31:13 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
17:37:00 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
17:38:45 <dave0> hi
17:38:53 <rdrop-exit> Hi dave0
17:39:14 <dave0> hi rdrop-exit 
17:40:46 --- quit: proteusguy (Ping timeout: 255 seconds)
18:05:12 --- quit: spestov (Ping timeout: 250 seconds)
20:01:22 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
20:14:20 --- quit: tabemann (Ping timeout: 250 seconds)
20:35:25 --- quit: spestov (Ping timeout: 245 seconds)
20:43:45 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth
20:43:45 --- mode: ChanServ set +v proteusguy
20:46:54 <proteusguy> corecode, I see your main.c file includes "forth.h" but I don't find forth.h in your github repo.
20:47:45 <proteusguy> nice going on the python, however. I'm likely to implement the first versions of ActorForth using python to bootstrap. Was either that or C++.
21:01:39 --- join: gravicappa (~gravicapp@h109-187-236-118.dyn.bashtel.ru) joined #forth
21:08:07 --- join: proteusguy2 (~yaaic@2001:44c8:4143:7aed:1:2:c3c4:4272) joined #forth
21:13:06 --- quit: rdrop-exit (Quit: Lost terminal)
22:03:31 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
22:07:37 --- quit: MrMobius (Ping timeout: 268 seconds)
22:07:37 --- nick: [1]MrMobius -> MrMobius
22:26:32 --- quit: proteusguy2 (Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org)
22:31:44 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
23:04:35 --- quit: spestov (Ping timeout: 246 seconds)
23:08:19 --- quit: dave0 (Quit: dave's not here)
23:59:59 --- log: ended forth/19.02.16