2024-06-26 10:38:20 historically Forth had an alternate stack where to put temporary items? 2024-06-26 10:38:49 Other than the return stack? 2024-06-26 10:41:39 Data/parameter stack, return stack, dictionary is a bit like a stack, PAD is a bit like a string register 2024-06-26 10:42:00 Temporary items were often put at addresses after HERE 2024-06-26 10:42:04 Like PAD 2024-06-26 10:59:29 rendar: if you need some space, you can ALLOT whatever you need 2024-06-26 10:59:59 i see 2024-06-26 11:00:31 dictionary = named variables? 2024-06-26 11:04:44 Yes, and words, and ALLOT 2024-06-26 11:04:58 All in one contiguous space (although sometimes machine code is separate) 2024-06-26 11:05:10 And sometimes headers are kept separately 2024-06-26 11:20:16 i see 2024-06-26 11:21:00 so using a dict involves allocating raw memory? 2024-06-26 11:22:02 In traditional Forth, the dictionary is what other languages would call the heap 2024-06-26 11:22:23 Space is allocated by moving a single pointer forward 2024-06-26 11:25:48 It's like the heap's underlying mechanism of sbrk(), it's also like statically allocated memory in the way it's just allocated in order 2024-06-26 11:25:58 It's a little of both as Forth compiles dynamically 2024-06-26 11:26:20 (Heaps use more than sbrk() now I know, but traditionally that's what it used) 2024-06-26 11:57:49 i see 2024-06-26 18:45:40 In gforth there's ALLOT which moves the dictionary pointer forward and ALLOCATE which returns a pointer to heap memory. 2024-06-26 19:17:58 ALLOT has a long history in Forth, all the way back to the beginning. At that time, I think it was presumed that was all the memory there was. Tons of RAM and the heap idea got added later as tech evolved. 2024-06-26 19:19:11 Temporary storage and reuse was done through loading and unloading of "overlays" 2024-06-26 19:24:19 forget was a thing 2024-06-26 19:24:35 now is deprecated? 2024-06-26 19:25:03 This word is obsolescent and is included as a concession to existing implementations. 2024-06-26 19:25:04 oh 2024-06-26 19:25:16 ah yeah, because of marker 2024-06-26 19:25:48 forget about forget 2024-06-26 19:30:45 forget didn't roll the allocation pointer back it just removed the dictionary entry 2024-06-26 19:55:37 dlowe so HERE was kept where it was? 2024-06-26 19:55:40 wtf 2024-06-26 19:56:09 what you would do after forget then? 2024-06-26 19:56:31 you just can't reuse that space or what 2024-06-26 19:56:36 nothing, because you forgot what you were doing 2024-06-26 19:56:40 :0 2024-06-26 20:00:30 you play it old school and when you run out of memory you reboot 2024-06-26 20:00:50 or write your own mark and sweep gc 2024-06-26 20:01:56 so the only goal of forget was to use an old definition and for some sort of temp definitions, but not to reuse space 2024-06-26 20:02:08 i thought it was for both 2024-06-26 20:03:37 i would expect forget to be more gentle, but in the starting forth book was depicted as a robber, so i can understand it now 2024-06-26 21:28:24 The main goal of FORGET was to recover dictionary space that you either no longer wanted or else needed to recompile. 2024-06-26 21:29:07 Since it was strictly "last compiled, first FORGOTten," it didn't really offer a robust general dynamic code handling facility. 2024-06-26 21:29:39 But at the time the computer system was generally being used for just one task, like controlling a telescope or something, so you'd FORGET and recompile to remove bugs and so on from your code. 2024-06-26 21:30:51 Later on as Chuck's work evolved he drifted toward just recompiling the entire system when he re-built. That is, it wasn't a "selective" forget - it was just "start over from scratch." 2024-06-26 21:31:03 Consequently he got really interested in compile speed for a wihle in there; he wanted that full system rebuild to be more or less instant. 2024-06-26 21:31:33 He's on record somewhere out there as boaste the ability to compile 100 MB of source code per second. 2024-06-26 21:32:03 That was when he was doing the chip design system, so most of that recompile was probably his integrated circuit specification. 2024-06-26 21:32:56 In the new system I'm planning I intend to give each vocabularly it's own block of RAM, so I'd be able to FORGET within each voc independently, or remove vocabularies completely in an order different from how I created them, etc. 2024-06-26 21:33:29 Within a vocabulary it will still be last compiled first forgotten, but at the vocabularly level it will be completely flexible. 2024-06-26 21:34:23 That will let me think of a vocbulary as an "application," so I'll be able to load it, use it, and unload it flexibly. 2024-06-26 21:59:42 KipIngram: that is a cool idea. do you plan to make that work on the max board you have? 2024-06-26 22:30:44 is forth for the guys who like to reinvent the wheel? 2024-06-26 22:51:09 : WHEEL SQUARE BEND ; 2024-06-26 22:51:25 :0 2024-06-26 22:52:00 veltas do you write all your forth code in caps? 2024-06-26 22:52:19 Yeah baby 2024-06-26 22:52:33 it's a convention? 2024-06-26 22:53:14 i like to give orders without having to yell them, but all the forth code i see is in caps 2024-06-26 22:53:53 The old forths were written before terminals with lowercase letters were widespread 2024-06-26 22:54:03 6-bit stuff 2024-06-26 22:54:24 but do you feel sad if you read forth code in lowercase? 2024-06-26 22:54:32 it might feel like it's not correct 2024-06-26 22:56:31 with the phone i have to keep pressing the shift, so i will write it in lowercase, but since eit seems to be the common way i would think about this if i write it from a computer 2024-06-26 22:57:04 I don't mind at all 2024-06-26 22:57:06 it might annoy some forth readers 2024-06-26 22:57:24 yeah as long as it's forth 2024-06-26 22:57:25 xD 2024-06-26 22:59:08 It's especially helpful in IRC to distinguish FORTH CODE from normal chat 2024-06-26 22:59:12 so you are case insensitive 2024-06-26 22:59:23 Yeah lol 2024-06-26 23:08:49 I write all my forth in lower case, unless I'm trying to do what veltas said and highlight it as code out of context. 2024-06-26 23:10:35 dlowe: fig forth moved DP to the def 2024-06-26 23:10:50 I can't imagine a lot of classic systems didn't recoup that memory, it would be quite wasteful 2024-06-26 23:11:32 It's the premier feature for unloading programs dynamically 2024-06-26 23:14:28 I have a question about interactive development. If I : LITTLEBIT something; and then : BIGBIT LITTLEBIT otherthing ; and then I need to change the way LITTLEBIT works, I have a few options: 2024-06-26 23:15:13 1. redefine both or 2. forget both and redefine. Is there a 3. redefine LITTLEBIT in such a way that BIGBIT now uses that? 2024-06-26 23:15:32 The standard feature is DEFER 2024-06-26 23:16:05 DEFER LITTLEBIT :NONAME ... ; IS LITTLEBIT :NONAME ... ; IS LITTLEBIT 2024-06-26 23:16:06 Is that a common practice? To defer everything until it's baked? 2024-06-26 23:16:48 I guess "common" is kinda meaningless in forthworld 2024-06-26 23:16:50 Or you can do this in ANS: VARIABLE 'LITTLEBIT : LITTLEBIT 'LITTLEBIT @ EXECUTE ; 2024-06-26 23:17:04 And store an xt in 'LITTLEBIT later to redefine 2024-06-26 23:17:33 I like the :noname tactic. Thanks for that. 2024-06-26 23:17:43 It's common for certain words where it's especially helpful 2024-06-26 23:18:05 Like gforth defers THROW and CATCH and TYPE and all sorts 2024-06-26 23:18:18 So you can extend their behaviour fully, without rebuilding the whole system 2024-06-26 23:18:38 Ah, yes, I've seen that where TYPE refers to (TYPE) etc 2024-06-26 23:18:54 Yeah maybe (TYPE) is deferred 2024-06-26 23:19:50 But something in there is deferred so you can dynamically e.g. make . output to a file (gforth can do that anyway, but you know what I mean) 2024-06-26 23:19:54 If I want to extend TYPE, I would expet to :noname mything (type) thisnthat ; is TYPE or somesuch 2024-06-26 23:20:27 Yes that looks right 2024-06-26 23:21:28 (TYPE) is ACTION-OF TYPE initially