00:00:00 --- log: started forth/21.03.28 00:06:00 --- join: f-a joined #forth 00:53:21 --- quit: f-a (Ping timeout: 252 seconds) 02:24:41 Is there a book that covers vocabularies and/or wordlists and provide conventions on how to use them? 02:52:29 I figured it out 03:41:10 --- join: tech_exorcist joined #forth 05:10:58 --- quit: dave0 (Quit: dave's not here) 06:14:48 Klaxon Suralis, what a name. 06:19:36 klaxon, klaxoff 06:30:20 --- quit: Zarutian_HTC1 (Remote host closed the connection) 06:47:41 you found a book? 06:47:42 ! 06:52:40 Just read up on the word definitions 06:53:06 Oh no, this one helped http://wiki.laptop.org/go/Forth_Lesson_21 06:55:35 vocabularies are not that difficult 06:56:08 a word header has a link field address, a name field address and maybe some other stuff 06:56:38 so you have <-link, "name" .... where each word links back to the previous one. the lfa at the end of the chain is of course zero 06:57:06 the vocabulary is an array of chains 06:57:33 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 06:57:40 rather than have one huge chain 06:57:46 this improves compile time 06:58:27 because. when you type foo enter forth computes a hash for "foo" and searches THAT chain within every single vocab thats in context 06:58:49 the current vocabulary is the one that always gets new definitions and the context stack defines the search order 06:58:54 no biggie :) 07:00:06 so in forth vocabularies help organize name spaces as it were but ALSO help speed up compilation times :) 07:50:32 I wonder what's a standard Forth implementaiton would amount to in terms of cloc 08:00:19 --- quit: cantstanya (Ping timeout: 240 seconds) 08:04:26 --- join: cantstanya joined #forth 08:18:45 --- join: f-a joined #forth 08:31:40 ? 08:44:21 Do you have a record in each header of what vocabulary it belongs to? 08:44:36 no 08:44:52 I'm thinking that I'll have an "in search order" linked list called PATH and an "not in search order" list called WEEDS. ;-) 08:45:00 So I'll be able to find them all that way. 08:45:20 Because you know, everyone is either on the path or in the weeds. 08:45:50 why is it important to know words that are not in the search order? 08:46:03 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. 08:46:13 Well, maybe I'm missing something. 08:46:30 But it seems to me when I forget I have to whack back each vocabulary to below the forget point. 08:46:59 Sure, I could just chop off the dictionary, but that might leave invalid vocabularies in my path or whatever. 08:47:16 Maybe FORGET would run ONLY FORTH. 08:47:25 just see if a voc is below the fense and if so remove it from context 08:47:41 and find the highest voc thats below fense and set that as the current voclink address 08:47:43 Well, I have to look at its dictonary entry to know that, right? 08:47:57 I have to check each one. 08:48:09 you can literally start at the bttom of your head space and scan each word header sequentially 08:48:17 So I have to find each one. I guess I could look at every word and recognize the vocs. 08:48:23 But that seems innefficient. 08:48:31 Sorry - my n key has been repeating on me. 08:49:13 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. 08:49:30 In the past I've had an array of vocs for CONTEXT. 08:49:37 I thought I'd try linked list this time. 08:49:54 Because I'll need linked list words for my command history anyway. 08:50:00 If I do it right I can use the same ones. 08:50:27 you dont need to purge your command history of references to words that have been forgotten 08:50:42 No, I just mean to implement commannd history. 08:50:48 I do that with a linked list of command strings. 08:50:55 No relation to vocs in that setting. 08:51:24 The alternative is an array of fixed length strings, but that's REALLY wasteful of RAM. 08:51:35 Since most lines are quite short. 08:52:15 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. 08:53:01 --- part: f-a left #forth 08:53:39 yea i use linked lists too if i remember rightly 09:21:41 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. 09:21:52 at "least" 09:26:45 mark4: Any locals mechanism? 09:33:04 no 09:55:39 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 09:55:41 traditionally, but fall back on this rather than let stack diddling become too onerous. 09:56:44 My mechanism doesn't support naming locals. It just has words that reach various distances below a "frame register." 09:57:44 It might not even deserve the name "locals." It's actually just a form of stack access. Like PICK, I suppose, except more capable. 09:58:08 It gives me the address of a slot, and then I can do anything I want with it. 10:22:43 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? 10:23:01 (I want interfaces + interface inheritance, don't really care about class inheritance) 10:24:16 (using my own forth, so looking for design advice / "fooforth does objects elegantly" more than "use the CLASS word in fooforth") 10:53:06 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 10:56:08 --- quit: gravicappa (Ping timeout: 252 seconds) 10:56:40 --- join: gravicappa joined #forth 11:26:54 i wouldnt oopify forth myself :) 11:27:18 it makes things ultra complificated, specially if you dont do GC 11:30:11 yeah, these at least last for the entire lifetime of the program 11:30:27 ...uhhh mostly 12:13:30 --- join: Zarutian_HTC joined #forth 12:19:23 --- quit: mark4 (Remote host closed the connection) 12:24:54 --- quit: Zarutian_HTC (Remote host closed the connection) 12:39:19 I'm with mark4 on this one. 12:44:41 I don't think GC is necessary at all 12:44:51 Not for dynamic dispatch anyway 12:58:36 remexre: https://pastebin.com/raw/yUPrivyk 12:58:46 Is that the sort of thing you're talking about? 13:02:06 GForth includes a library that provides object-oriented support for standard forths called OOF, you might want to check that 13:04:32 --- quit: gravicappa (Ping timeout: 268 seconds) 13:10:25 I think there's very little that GForth doesn't propose to support. :-) 13:11:06 Well they said they don't want to know about specific forths, but this library is supposedly 'mostly' standard 13:12:45 --- join: inode joined #forth 13:17:00 --- quit: inode (Ping timeout: 240 seconds) 13:19:34 --- quit: lispmacs[work] (Read error: Connection reset by peer) 13:27:03 back now :) 13:27:23 veltas: yeah, that looks right 13:27:36 I'll give it a look, thanks 13:45:12 I hope it at least helps the juices flow 13:45:48 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 13:45:53 Obviously that is not always possible 14:05:03 --- join: inode joined #forth 14:43:40 --- quit: inode (Ping timeout: 240 seconds) 15:21:17 --- join: mark4 joined #forth 16:04:04 --- quit: tech_exorcist (Quit: tech_exorcist) 16:35:36 --- join: jedb_ joined #forth 16:37:48 --- quit: jedb (Ping timeout: 240 seconds) 16:43:35 back 16:56:58 --- quit: xek_ (Ping timeout: 260 seconds) 17:06:06 --- join: dave0 joined #forth 17:38:01 --- join: jedb__ joined #forth 17:40:20 --- quit: jedb_ (Ping timeout: 240 seconds) 18:32:45 --- quit: dave0 (Quit: dave's not here) 18:48:48 --- join: boru` joined #forth 18:48:50 --- quit: boru (Disconnected by services) 18:48:53 --- nick: boru` -> boru 19:18:01 --- join: dave0 joined #forth 19:54:00 --- quit: sts-q (Ping timeout: 240 seconds) 19:57:16 --- join: sts-q joined #forth 20:40:11 --- quit: dave0 (Quit: dave's not here) 22:31:07 --- join: dave0 joined #forth 22:42:55 --- join: gravicappa joined #forth 22:50:20 --- join: hosewiejacke joined #forth 22:52:00 --- quit: shmorgle (Ping timeout: 240 seconds) 22:55:36 --- join: f-a joined #forth 23:43:30 --- join: nihilazo joined #forth 23:48:38 --- quit: pareidolia (Ping timeout: 245 seconds) 23:55:52 --- join: pareidolia joined #forth 23:59:59 --- log: ended forth/21.03.28