Zarutian_HTC has quit [Remote host closed the connection]
Zarutian_HTC has joined #forth
proteus-guy has quit [Remote host closed the connection]
dave0 has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
mark4 has joined #forth
nihilazo has quit [Ping timeout: 240 seconds]
sts-q has quit [Ping timeout: 240 seconds]
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC1 has joined #forth
sts-q has joined #forth
dave0 has quit [Quit: dave's not here]
<KipIngram>
mark4: do you use vocabularies? If so, how do you cope with markers / forgetting when a lot of vocabularly activity is involved? Do you store the current state of every vocabulary in the marker in some way?
clog has quit [Ping timeout: 252 seconds]
<KipIngram>
Or do you run through all the vocabularies and trim them all back to the right place?
gravicappa has joined #forth
<mark4>
yes i do and when i forget i scan all words above the one being forgotten
<mark4>
and i can forget an entire vocabulary esily and unchain it from the voc chain
<mark4>
if a voc is in context its removed, if its current forth is made current
<mark4>
a word header has a link field address, a name field address and maybe some other stuff
<mark4>
so you have <-link, "name" .... <link, "name"
<mark4>
where each word links back to the previous one. the lfa at the end of the chain is of course zero
<mark4>
the vocabulary is an array of chains
<mark4>
when you create a new word the compiler computes a hash value and uses that as an index into the vocab to decide which chain it will be attached to
<mark4>
rather than have one huge chain
<mark4>
this improves compile time
<mark4>
because. when you type foo enter forth computes a hash for "foo" and searches THAT chain within every single vocab thats in context
<mark4>
the current vocabulary is the one that always gets new definitions and the context stack defines the search order
<mark4>
no biggie :)
<mark4>
so in forth vocabularies help organize name spaces as it were but ALSO help speed up compilation times :)
<neuro_sys>
I wonder what's a standard Forth implementaiton would amount to in terms of cloc
cantstanya has quit [Ping timeout: 240 seconds]
cantstanya has joined #forth
f-a has joined #forth
<mark4>
?
<KipIngram>
Do you have a record in each header of what vocabulary it belongs to?
<mark4>
no
<KipIngram>
I'm thinking that I'll have an "in search order" linked list called PATH and an "not in search order" list called WEEDS. ;-)
<KipIngram>
So I'll be able to find them all that way.
<KipIngram>
Because you know, everyone is either on the path or in the weeds.
<mark4>
why is it important to know words that are not in the search order?
<KipIngram>
But I did realize they couldn't just be scattered around randomly - I need to know how to reach all of them, as a group.
<KipIngram>
Well, maybe I'm missing something.
<KipIngram>
But it seems to me when I forget I have to whack back each vocabulary to below the forget point.
<KipIngram>
Sure, I could just chop off the dictionary, but that might leave invalid vocabularies in my path or whatever.
<KipIngram>
Maybe FORGET would run ONLY FORTH.
<mark4>
just see if a voc is below the fense and if so remove it from context
<mark4>
and find the highest voc thats below fense and set that as the current voclink address
<KipIngram>
Well, I have to look at its dictonary entry to know that, right?
<KipIngram>
I have to check each one.
<mark4>
you can literally start at the bttom of your head space and scan each word header sequentially
<KipIngram>
So I have to find each one. I guess I could look at every word and recognize the vocs.
<KipIngram>
But that seems innefficient.
<KipIngram>
Sorry - my n key has been repeating on me.
<KipIngram>
If I've already got linked list pointers in the voc entries, for putting them in the path list, it's easy to use the same pointers to keep them in another list.
<KipIngram>
In the past I've had an array of vocs for CONTEXT.
<KipIngram>
I thought I'd try linked list this time.
<KipIngram>
Because I'll need linked list words for my command history anyway.
<KipIngram>
If I do it right I can use the same ones.
<mark4>
you dont need to purge your command history of references to words that have been forgotten
<KipIngram>
No, I just mean to implement commannd history.
<KipIngram>
I do that with a linked list of command strings.
<KipIngram>
No relation to vocs in that setting.
<KipIngram>
The alternative is an array of fixed length strings, but that's REALLY wasteful of RAM.
<KipIngram>
Since most lines are quite short.
<KipIngram>
At some point in the past I've come up with some really nice and tight doubly linked list words. I'll hunt those down and use them.
f-a has left #forth [#forth]
<mark4>
yea i use linked lists too if i remember rightly
<KipIngram>
It took a little while to find that algorithm - most of the ways you start thinking about approaching double linked lists get ugly pretty fast. But there's at lease one way that seems pretty tidy.
<KipIngram>
at "least"
<KipIngram>
mark4: Any locals mechanism?
<mark4>
no
<KipIngram>
I've been using one - a very simple and inexpensive one - the last couple of rounds. I don't really use it "routinely," but there are a couple of tasks in the system that it really cleans up. The line editing when reading a line from the keyboard is one, and so is navigating the command history, tough those wind up being the same usage. Searching the full dictionary is another. So I try to do things
<KipIngram>
traditionally, but fall back on this rather than let stack diddling become too onerous.
<KipIngram>
My mechanism doesn't support naming locals. It just has words that reach various distances below a "frame register."
<KipIngram>
It might not even deserve the name "locals." It's actually just a form of stack access. Like PICK, I suppose, except more capable.
<KipIngram>
It gives me the address of a slot, and then I can do anything I want with it.
<remexre>
what do people use for "object-like systems"; I have a bunch of "things," with a few words of variables, plus I want something dynamic-dispatch-like; should I just make defining words to define "classes" as words that allocate/initialize objects with a vtable-like-structure?
<remexre>
(I want interfaces + interface inheritance, don't really care about class inheritance)
<remexre>
(using my own forth, so looking for design advice / "fooforth does objects elegantly" more than "use the CLASS word in fooforth")
<veltas>
I don't know what to suggest for doing dynamic dispatch elegantly, at least no more elegantly than storing a 'type' number at start of data
gravicappa has quit [Ping timeout: 252 seconds]
gravicappa has joined #forth
<mark4>
i wouldnt oopify forth myself :)
<mark4>
it makes things ultra complificated, specially if you dont do GC
<remexre>
yeah, these at least last for the entire lifetime of the program
<remexre>
...uhhh mostly
Zarutian_HTC has joined #forth
mark4 has quit [Remote host closed the connection]
Zarutian_HTC has quit [Remote host closed the connection]
<veltas>
Is that the sort of thing you're talking about?
<veltas>
GForth includes a library that provides object-oriented support for standard forths called OOF, you might want to check that
gravicappa has quit [Ping timeout: 268 seconds]
<KipIngram>
I think there's very little that GForth doesn't propose to support. :-)
<veltas>
Well they said they don't want to know about specific forths, but this library is supposedly 'mostly' standard
inode has joined #forth
inode has quit [Ping timeout: 240 seconds]
lispmacs[work] has quit [Read error: Connection reset by peer]
<remexre>
back now :)
<remexre>
veltas: yeah, that looks right
<remexre>
I'll give it a look, thanks
<veltas>
I hope it at least helps the juices flow
<veltas>
I often find, however, that it's better if you can just fit the data to match every case, rather than try and provide alternative data layouts that can be handled automatically