mark4 changed the topic of #forth to: Forth Programming | do drop >in | logged by clog at backup at | If you have two (or more) stacks and speak RPN then you're welcome here! |
j has joined #forth
j is now known as jess
inode has quit []
tech_exorcist has quit [Quit: tech_exorcist]
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> in (trim) the >name is not actually a >name operation, im cheating lol
<mark4> thats literally a cell- @ from the nfa to the nfa of the previous word in the chain
clog has joined #forth
dave0 has joined #forth
f-a has joined #forth
f-a has quit [Ping timeout: 252 seconds]
<neuro_sys> Is there a book that covers vocabularies and/or wordlists and provide conventions on how to use them?
<neuro_sys> I figured it out
tech_exorcist has joined #forth
dave0 has quit [Quit: dave's not here]
<neuro_sys> Klaxon Suralis, what a name.
<cmtptr> klaxon, klaxoff
Zarutian_HTC1 has quit [Remote host closed the connection]
<mark4> you found a book?
<mark4> !
<neuro_sys> Just read up on the word definitions
<neuro_sys> Oh no, this one helped
<mark4> vocabularies are not that difficult
<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]
<KipIngram> I'm with mark4 on this one.
<veltas> I don't think GC is necessary at all
<veltas> Not for dynamic dispatch anyway
<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
<veltas> Obviously that is not always possible
inode has joined #forth
inode has quit [Ping timeout: 240 seconds]
mark4 has joined #forth
tech_exorcist has quit [Quit: tech_exorcist]
jedb_ has joined #forth
jedb has quit [Ping timeout: 240 seconds]
<tabemann> back
xek_ has quit [Ping timeout: 260 seconds]