00:18:34
##forth
<ajhidd>
What would become of mistyped words? Will they just sit out there as dead weight?
00:28:45
##forth
<cleobuline>
for me all is discarded
00:37:40
##forth
<cleobuline>
it does not make sense to call undefined words
01:40:01
##forth
<crc>
KipIngram: I've never tried that, though I once did a system where all words were essentially deferred. Unknown names would just add a header pointing to a nop which would be replaced later when the word was properly defined.
01:56:17
##forth
<forthBot>
Environment for cleobuline inactive, freeing...
06:06:50
##forth
<MrMobius>
Ya all words are deferred and set to error if you try to execute them
06:07:25
##forth
<MrMobius>
I also have syntax highlighting which helps figure out what still needs to be defined
12:03:26
##forth
<KipIngram>
MrMobius - yeah; it sounds like what I was thinking of was just a much shorter-term version of what you're doing.
12:46:47
##forth
<MrMobius>
KipIngram: I was also thinking something similar to what you mean when I was talking about buffering words before they're written so that the words can see the buffer and make changes
12:48:31
##forth
<MrMobius>
so in your example of `name :` the : would look at the buffer and spot the word that came before
14:13:11
##forth
<KipIngram>
Yes - the system would hold it somewhere and pend a not found error, but : would be able to pick it up from that place, do its work, and clear the error. And then we'd be exactly where we'd normally be after : <name>
16:27:06
##forth
<KipIngram>
Something I find rather amusing. If you watch YouTube presentations on Erlang, from Joe Armstrong and other creators of the thing, they really bang the "no shared memory" / "immutable" drum hard. But once you start clawing around in how Erlang really works you discover both of those things are compromised. For example, they have a thing called the ETS where stuff like database tables get stored,
16:27:08
##forth
<KipIngram>
and yes - multiple processes can go mucking about with that stuff at the same time.
16:28:06
##forth
<KipIngram>
The seem to settle for not letting USER CODE do so - you don't get actual pointers to ETS items. You get references, or "handles," and you have to pass those to system calls and that's where the shared access happens. But it is NOT pure message passing they way they say it is.
16:28:30
##forth
<KipIngram>
And there's also some kind of "registry" that is basically a key/value table, and yes, you can change the values associated with keys - those keys are mutable.
16:28:52
##forth
<KipIngram>
So there's an element of "do what we say, not what we do" going on with the whole business.
16:29:41
##forth
<KipIngram>
My guess is that they went into the process intent on being purists but then discovered (surprise surprise...) that they couldn't get the performance they needed without engaging in some of that shady business they hated.
16:30:57
##forth
<KipIngram>
It doesn't surprise ME - it seems clear to me that the world simply is not immutable. I guess there are some problems where those nice ivory tower processes fit really nicely, but it's certainly not all problems.
16:32:50
##forth
<KipIngram>
I'm snitching some ideas from Erlang for this next system I'm planning (and some ideas from APl, and some from ...). So I've been digging around in it recently.
16:34:00
##forth
<KipIngram>
I like the "many small processes" idea, and I generally like the messge passing notions for the primary way they interact. But I'm not going in for immutability at all.