2021-12-20 11:33:54 I do apologize, but it seems I've littered this channel with zombie nick accounts. Could someone please kick "eukarya", "eukarya_" and "eukarya__" from this channel? Thanks for the assistance. I apologize for the inconvenience. 2021-12-20 11:40:24 eukarya__: maybe they will ping timeout themselves soon 2021-12-20 15:01:22 Why do forth implementations usually use a linked list as the dictionary instead of a hashmap? 2021-12-20 15:03:29 I guess it easier to implement from scratch? 2021-12-20 15:03:43 maybe because looking up a word is fast enough already if you only have a few hundred 2021-12-20 15:04:21 so not worth the trouble to rehash after every word or whatever it is you have to do 2021-12-20 15:53:30 If it's fast enough for an 8-bit chip.... 2021-12-20 15:54:24 It's simpler and fast enough. FORTH attitude is to solve problems in as simple a way that works 2021-12-20 16:06:16 i read or maybe saw a youtube video about forth on an RCA 1802 that was very slow to use because of dictionary lookup 2021-12-20 16:06:47 i thought about putting two pointers in the linked list to do a binary search 2021-12-20 16:18:04 I'm not sure if the lookup speed is that significant of an issue in practice. 2021-12-20 16:23:35 My forth isn't particularly quick(*), but even so it's more than adequate for sources up to a few thousand words. 2021-12-20 16:26:39 Hey we still compile way faster than C++, Rust, Zig, et al 2021-12-20 16:27:13 Don't know about C tho there are some pretty fast C compilers, but whether you use FORTH or C you're not sitting around waiting 2021-12-20 16:30:17 to throw in my 2 cents: I would imagine speed is not a real big deal in the word lookup, because in practice you are going to be running the word from another compiled word, and once compiled in you no longer have to do the lookup 2021-12-20 16:30:44 Exactly, it's O(words*program-length) 2021-12-20 16:30:48 The second it becomes a problem it's not *that* hard to convert to a hash table instead 2021-12-20 16:31:26 I would think the downside with the hash table is, during resize, you have to allocate memory near the memory you've already allocated, right? 2021-12-20 16:31:44 whereas in a lot of forths the dictionary memory is shared with other memory 2021-12-20 16:31:52 allocated memory 2021-12-20 16:32:04 It depends how you do it I think 2021-12-20 16:32:22 with the link list you just link to whereever the available memory pointer is pointing now 2021-12-20 16:32:45 You could put everything in dictionary except the word table, then it's still forgettable and resizable as normal 2021-12-20 16:33:01 Just link to the main dictionary space from the table 2021-12-20 16:33:57 but then you need to have extra space available in advance for the table resize, not be used for anything...? 2021-12-20 16:35:18 unless you just want a fixed sized table, which maybe is fine in some situations 2021-12-20 16:36:08 of course, tables turn into link lists when there are slot collisions 2021-12-20 16:36:14 Oh I see what you are saying, well it depends I guess 2021-12-20 16:40:41 Sometimes you have a choice between performance and space 2021-12-20 16:41:48 The 'dictionary' in FORTH is quite similar to a lot of early data stores for programming languages, honestly. It's slow but saves space, which there was precious little of 2021-12-20 16:42:59 and it is the simplest data structure fit for the task 2021-12-20 17:38:43 When neuro_sys gets back somebody tell them about R. 2021-12-20 17:39:05 They were asking about it earlier "how to print right-aligned number fields" (paraphrased) 2021-12-20 17:39:31 Other than using <# #s #> etc