2026-06-28 04:15:08 <Stalevar    > I have finished reading Starting Forth chapter 1 and did the problems which are trivial, but it has one question, why if you define a word which depends on other words and then redefine the underlying word, the first word will still use the old definition. I understand why, but I feel like I missed the explanation in the book Starting Forth itself. The problem is that when you compile a word it will be a sequence of other words, but sequence uses
2026-06-28 04:15:08 <Stalevar    > memory addresses or indices instead of word names.
2026-06-28 04:15:52 <Stalevar    > But I could imagine a forth implementation which uses word name itself as its key, then if you redefine a word, all previously defined ones will change behavior
2026-06-28 04:16:08 <Stalevar    > So question, do such implementations exist or it will no longer be Forth?
2026-06-28 04:17:19 <Stalevar    > And question 2, where did I miss the explanation? I don't feel like rereading the chapter, I already spend several days because I constantly got distracted, for example I read about TIB and started to try things to modify it (example above)
2026-06-28 04:20:55 <Stalevar    > Don't feel like rereading the chapter to just find what I already understand, but I just knew it before reading
2026-06-28 04:22:16 <Stalevar    > By the way if you want to emit a specific character, '!' EMIT works, I wonder if it's gforth, or universal forth feature
2026-06-28 04:25:16 <lofty       > EMIT is a forth-2012 word, at least
2026-06-28 04:25:22 <oak         > Q: How would one create a new word whose name comes from a string I have stored in memory (i.e. not the input buffer)? Something like CREATE but not using look-ahead for its name.
2026-06-28 04:55:06 <Stalevar    > oak, a hacky way is to copy the string to TIB
2026-06-28 04:55:19 <oak         > TIB?
2026-06-28 04:55:21 <Stalevar    > Then it will be in input buffer
2026-06-28 04:55:29 <Stalevar    > The Input Buffer
2026-06-28 04:55:39 <oak         > Wouldn't that overwrite existing data?
2026-06-28 04:55:54 <Stalevar    > Yes, but if you put enough spaces it should work
2026-06-28 04:56:33 <oak         > Oof. That seems really fragile. I appreciate the idea though. :)
2026-06-28 04:56:49 <oak         > I was hoping there was a standard way to do it.
2026-06-28 04:57:13 <oak         > cc xentrac ^
2026-06-28 04:58:56 <Stalevar    > 0 tib 15 + ! : dup drop ." Hello world!" ;
2026-06-28 04:58:56 <Stalevar    > tib 21 + 0 swap ! cr drop dup cr
2026-06-28 04:59:22 <Stalevar    > oak, my example, I wanted to see what happens if you define a word which only has 0x00 bytes. Turns out it works as any other name
2026-06-28 05:00:29 <Stalevar    > Since it's impossible to type directly with line-editing enabled I used this and it worked
2026-06-28 05:00:43 <oak         > Stalevar: I don't understand.
2026-06-28 05:00:51 <oak         > I am thinking that EVALUATE could work for this though.
2026-06-28 05:02:23 <oak         > Oh nice, yeah: s" variable foo" EVALUATE
2026-06-28 05:02:26 <oak         > easy peezy
2026-06-28 05:02:34 <oak         > ^__^
2026-06-28 05:02:57 <Stalevar    > oak, or you could look the source code of your forth implementation and see how : is done
2026-06-28 05:03:05 <Stalevar    > And create
2026-06-28 05:03:20 <Stalevar    > They probably call to some lower level word which you can use?
2026-06-28 05:03:23 <oak         > I think EVALUATE would be more portable.
2026-06-28 05:03:45 <Stalevar    > I dunno. Still check it out? Eval is usually very bad idea if you process user data
2026-06-28 05:04:20 <Stalevar    > In meantime if you use string as name of word, it can be anything, even maybe contain spaces (though you wouldn't be able to call it at all then)
2026-06-28 05:04:43 <oak         > Even if you use the input buffer, you're still operating on user data.
2026-06-28 05:04:58 <oak         > Your ideas don't seem any safer?
2026-06-28 05:05:06 <Stalevar    > Yes, if you put it in TIB it will be same as eval
2026-06-28 05:05:26 <oak         > So might as well use the most portable, least fragile option. :3
2026-06-28 05:05:31 <Stalevar    > The other idea however is safer, to use word which is underneath create, :, variable, constant, value
2026-06-28 05:05:41 <Stalevar    > See source code of those and check what's in common
2026-06-28 05:06:00 <Stalevar    > They probably use something
2026-06-28 05:06:16 <oak         > *nods* I hear that. For my use case this is sufficient.
2026-06-28 05:25:37 <Stalevar    > oak, it seems that word header does it
2026-06-28 05:35:07 <Stalevar    > oak, it seems that header takes a string
2026-06-28 05:37:17 <Stalevar    > Hm, no, it still looks in input stream
2026-06-28 07:08:34 <xentrac     > Stalevar: I think ColorForth and the earliest Forths like https://github.com/monsonite/1968-FORTH did change the behavior of all previously defined words when you redefined one.  it seems like a valid approach to me, but it probably will create an incentive to use a larger number of different namespaces
2026-06-28 07:11:05 <xentrac     > oak: I don't think there's a standard way to create a new word whose name comes from a string you have stored in memory other than by putting it into the input buffer, but I'm no expert
2026-06-28 07:11:26 <xentrac     > evaluate does put it in the input buffer :-)
2026-06-28 07:12:22 <xentrac     > of course you can do it in any particular Forth, just not in a standard portable way
2026-06-28 08:15:49 <Stalevar    > xentrac, but you can go down the rabbit hole from : implementation and on. Like header, but it seems to take the word from input buffer too
2026-06-28 08:16:18 <Stalevar    > I also didn't get how to use header to create a word
2026-06-28 16:21:32 <Stalevar    > I have found a kinda-mistake in STARTING FORTH chapter 2. It said "it's best to factor them out" and as example offered a²+ab = a(a+b), adding that it's difficult or even impossible to solve the original problem with operators it discussed, however I found it's quite easy:  : nofactoring ( a b -- a²+ab ) over dup * rot rot * + ;
2026-06-28 16:21:49 <Stalevar    > -rot works instead of rot rot but it is not mentioned in the book
2026-06-28 16:22:47 <Stalevar    > Though : factored over + * ; is indeed shorter
2026-06-28 16:23:34 <Stalevar    > Is the rule that factoring simplifies RPN universal?
2026-06-28 16:26:50 <Stalevar    > Not quite mistake, just different margin what's difficult
2026-06-28 16:27:23 <Stalevar    > But I don't think there are impossible expressions even if you skip factoring and try to implement all operators as written
2026-06-28 16:29:42 <deadmarshal > without factoring would become longer and probably needs more stack juggling
2026-06-28 16:30:28 <deadmarshal > Idk if book has mistake. but there are places where he deliberately asks questions where you can't answer them, and points it out later
2026-06-28 16:33:35 <Stalevar    > deadmarshal, yeah, I have seen one, a problem which is claimed to be impossible, but of course I knew swap and did it anyway
2026-06-28 16:33:58 <Stalevar    > I am not sure I'm not wasting my time reading Starting Forth given I already know RPN and stack words
2026-06-28 17:13:00 <Stalevar    > : .S CR 'S S0 @ 2- DO I @ . -2 +LOOP ;  The book said to type in this word, but it's outdated because modern forths have it out of the box. It  might be interesting to figure out how it's supposed to work (even if it said not to worry about it). However, if  I was writing the book, I'd add a page explaining each operator with a note like "If you don't understand it yet, don't worry, I am writing that for inquisitive peers who want to know what this
2026-06-28 17:13:00 <Stalevar    > stuff is about"
2026-06-28 18:07:21 <xentrac     > Stalevar: if you are talking about header, you are talking about some specific Forth implementation, not the standard; there is no header in https://forth-standard.org/standard/alpha
2026-06-28 18:08:56 <xentrac     > I think the rule that factoring simplifies *programming* is universal --- but only up to a point
2026-06-28 18:09:07 <xentrac     > and of course only the correct factoring
2026-06-28 18:09:22 <Stalevar    > xentrac, by the way I know one guy who said that committee standards are absolute evils and people shouldn't care about them. Though they make distinction about specifications. Specifications are not "standards" and they are fine, as example of good specs he lists first thousand RFCs
2026-06-28 18:10:05 <xentrac     > yes, I'm not saying it's bad to talk about a specific Forth, or to write Forths that don't comply with the standard
2026-06-28 18:10:16 <xentrac     > but you should maybe clarify which one you mean in that case
2026-06-28 18:12:28 <xentrac     > also it seemed like you were disagreeing with me ("xentrac, but you can...") but finding a way to do it in a particular Forth would not constitute disagreement; my last line immediately before that was "of course you can do it in any particular Forth, just not in a standard portable way"
2026-06-28 18:16:17 <xentrac     > there's of course a certain amount of ambiguity around "standard", often exploited by advocates of particular specifications; you are correct to observe that "specification" is a more neutral term
2026-06-28 18:22:14 <xentrac     > but it lacks the crucial load-bearing semantic element: a standard is a *widely implemented* specification
2026-06-28 18:23:09 <xentrac     > as well as, ambiguously, sometimes being "the required level of quality" --- an ambiguity that opponents of standards are right to complain about
2026-06-28 18:27:02 <xentrac     > in the context of industrial mass production and engineering, these two meanings are closely related: something sold as an M6-1.0 machine screw but with a thread pitch of 1.2 mm instead of the specified 1.0 mm is very poor quality, considered as an M6-1.0 machine screw
2026-06-28 18:27:27 <xentrac     > but it might be an acceptable-quality ¼-20 SAE machine screw
2026-06-28 18:28:26 <xentrac     > so it's not up to the standard² because it's the wrong standard¹
2026-06-28 18:29:35 <xentrac     > I should say: so it's not up to the standard² because the screw is made for the wrong standard¹
2026-06-28 18:32:07 <xentrac     > an excellent ¼-20 machine screw is a horrifyingly bad M6-1.0 machine screw and vice versa.  and there isn't really a principled way to distinguish between a part that someone screwed up on making on the lathe and a part that they made perfectly well for some other purpose
2026-06-28 20:05:05 <crc         > Oak: you might look at EXECUTE-PARSING. There's a public domain implementation for gforth at https://github.com/forthy42/gforth/blob/master/compat/execute-parsing.fs
2026-06-28 20:49:05 <oak         > Thank you, crc. And xentrac for your notes.
2026-06-28 20:50:20 <oak         > crc: I'm still pretty new to Forth, so I definitely don't understand all of this code, but I notice it ultimately uses EVALUATE. I'm wondering what the benefit is to all of this input buffer manipulation if one can just do ." foo CREATE" EVALUATE? Is this code here somehow safer or otherwise better?
2026-06-28 20:56:12 <crc         > iirc, the forth200x standard will include this as part of the standard
2026-06-28 21:01:36 <crc         > I think the main advantage is that it can be used with any of the parsing words and it ensures the input stream is kept intact for the calling word
2026-06-28 21:03:46 <oak         > crc: "Parsing words" are words that do look-ahead, right?
2026-06-28 21:04:06 <crc         > Yes
2026-06-28 21:04:26 <oak         > I'm struggling to understand what you mean by "the input stream is kept intact for the calling word". Can you explain that a bit more?
2026-06-28 21:04:31 <oak         > Thanks!
2026-06-28 21:10:46 <crc         > it's been a while since I used ans forth
2026-06-28 21:10:49 <crc         > evaluate should normally take a read-only string, set it as the input source, evaluate it, then reset to the prior source when done
2026-06-28 21:11:39 <crc         > If the source string is separate, in a non-transient buffer it's probably fine
2026-06-28 21:12:01 <crc         > You'd need to make sure of that in your system before calling it
2026-06-28 21:13:37 <crc         > I don't recall if ans requires S" to return a string in a dedicated buffer
2026-06-28 21:14:32 <crc         > I know the EXECUTE-PARSING code allocates a buffer to use, then frees it when evaluation is complete
2026-06-28 21:17:16 <crc         > (I dropped most use of parsing words outside of use in applications in my forth systems a long time ago, so am rather rusty on this)
2026-06-28 21:27:14 <oak         > Interesting! If the source string is in transient storage, there's a risk of it being overridden or modified between S" and EVALUATE?
2026-06-28 21:30:04 <crc         > Yes, depending on the system, transient buffers might be used for different things in the system.
2026-06-28 21:30:27 <vms14       > will you guys participate in the cat lang jam?
2026-06-28 21:31:04 <crc         > Especially if the string is created at interpret time
2026-06-28 21:31:10 <vms14       > https://itch.io/jam/catjam-2026
2026-06-28 21:33:17 <crc         > vms14: thanks; hadn't seen that. I'll see if I can find time to put something interesting together for it
2026-06-28 21:33:35 <vms14       > crc: starts soon, but lasts two months
2026-06-28 21:34:25 <vms14       > i want to try a vampire survivors clone with my toy lang
2026-06-28 21:34:26 <crc         > The two months makes it easier, but summer is a busy time for me
2026-06-28 21:35:19 <oak         > crc: That makes sense. Thank you for taking the time to chat it through with me.
2026-06-28 21:35:59 <oak         > vms14: I'm not sure yet if I'll participate.
2026-06-28 21:36:54 <crc         > oak: no problem.  I watch the channel, though I have long idle times. I'll try to answer questions as I have time, though you might have to look in the logs if you're not present when I answer.
2026-06-28 21:37:43 <oak         > 
ACTION nods

2026-06-28 21:38:02 <oak         > crc: Can I ask -- what's your history with Forth?
2026-06-28 21:41:34 <oak         > (Thank you also, Stalevar.)
2026-06-28 21:42:30 <crc         > My history goes back to around 1997 or 1998. I started using Forth then, while working on my own little OS. I ported RetroForth to it. A few years later, I took over development of RetroForth itself, and have run that and developed/helped develop several other system (a couple of notable ones include glypher, a colorforth for windows, and the original version of reva, which eventually led to https://8th-dev.com/) over the years.
2026-06-28 21:43:47 <crc         > I also write actual applications that are used by the company I work for, and have done some consulting and contract work in Forth.
2026-06-28 21:47:03 <crc         > (Most of the code I've written in the last two decades has been in either Forth or assembly)
2026-06-28 21:48:49 <oak         > That's really cool.
2026-06-28 21:48:58 <Stalevar    > crc, can you explain what's wrong with 03color04Forth so Chuck Moore can't use it anymore?
2026-06-28 21:49:16 <Stalevar    > Did you develop it independently or it's same version he's trying to fix?
2026-06-28 21:49:22 <Stalevar    > Why not to help him?
2026-06-28 21:50:19 <crc         > Glypher stopped working after Windows 7, I never really tried to fix it as I mostly don't use Windows for dev work now.
2026-06-28 21:51:09 <Stalevar    > What's glypher?
2026-06-28 21:51:49 <Stalevar    > Also I'm quite surprised a seasoned hacker like Chuck Moore is using Windows at all
2026-06-28 21:52:19 <crc         > Assuming that Chuck's most recent colorForth models continues with the same approach he had been using, Windows 10 & 11 seem to have made changes that make use of self modifying code more difficult, and I think he had issues with how he was handling the display
2026-06-28 21:52:58 <crc         > (Glypher was a colorForth that was built using thr more of RetroForth 7/8)
2026-06-28 21:53:15 <Stalevar    > crc, Yes, but did you write that particular CF for windows which is used by Chuck or different port?
2026-06-28 21:53:46 <crc         > No, I only briefly used his original colorForth
2026-06-28 21:54:07 <Stalevar    > Hm, I thought CF exists in some ancient files on obscure FTP or something, but then there are multiple implementations? Hmm
2026-06-28 21:54:15 <crc         > His version was custom, and I don't think was ever published
2026-06-28 21:55:10 <crc         > The original was ported to a few systems (I recall a version running under X11 on 32-bit Linux), and a few people maintained their own forks of it for a few years
2026-06-28 21:55:19 <Stalevar    > https://www.reddit.com/r/Forth/comments/1ozsajc/windows_update_break_colorforth_chuck_thinks/
2026-06-28 21:56:47 <Stalevar    >  This url contains under the header ARRAYFORTH an emulated colorforth that runs on a linux system. Contrary to Moore's habit, the source is amenable to storage in a source control system. There is a configuration of vim that reproduces the original colors. There is also a tutorial.txt.
2026-06-28 21:56:47 <Stalevar    > I have found an archive that contains the original colorforth that boots from a floppy drive. There is the binary, and the recovered source, and a program that is to this day able to regenerate the binary. The recovered source is complete, including bitmaps for the characters!
2026-06-28 21:57:32 <Stalevar    > >  This url contains under the header ARRAYFORTH an emulated colorforth that runs on a linux system. Contrary to Moore's habit, the source is amenable to storage in a source control system. There is a configuration of vim that reproduces the original colors. There is also a tutorial.txt.
2026-06-28 21:57:33 <Stalevar    > I have found an archive that contains the original colorforth that boots from a floppy drive. There is the binary, and the recovered source, and a program that is to this day able to regenerate the binary. The recovered source is complete, including bitmaps for the characters!
2026-06-28 21:57:41 <oak         > Wow, 8th has a very extensive standard library. Shame it's proprietary. I wonder if anyone has collected a regular Forth collection of such utilities.
2026-06-28 21:58:16 <Stalevar    > > He could have put his efforts on github and I'm sure the community would help him out. Unfortunately this is not his style. As far as I can tell the OKAD is lost forever too.
2026-06-28 21:58:49 <crc         > I never saw a release of OKAD; I'd have archived it
2026-06-28 21:59:24 <Stalevar    > In particular those lines. It seems that alberthemagician 's FTP is broken and also I have tried too look at lina but found out the tarball was wiped and had txt file saying it's not available and you need to write to email
2026-06-28 22:00:14 <Stalevar    > crc, is lina any good? But I find it suspicious when old tarballs are retroactively removed and not sure I can trust it
2026-06-28 22:00:57 <Stalevar    > crc, so Moor has OKAD, but can't use anymore and wouldn't release it?
2026-06-28 22:01:04 <Stalevar    > or he doesn't have it either?
2026-06-28 22:01:56 <crc         > Not sure; I last used lina a long time ago
2026-06-28 22:02:10 <Stalevar    > If Moore has it on his PC then it's not lost forever yet?
2026-06-28 22:02:29 <crc         > I think he had moved on from the original OKAD when he began doing colorForth
2026-06-28 22:02:52 <Stalevar    > So he might or might not have it
2026-06-28 22:03:06 <Stalevar    > Because it's so old it might be on some old unreadable diskette
2026-06-28 22:03:13 <crc         > https://github.com/albertvanderhorst/ciforth has lina
2026-06-28 22:05:35 <crc         > OKAD was written during his "sourceless" experiment iirc
2026-06-28 22:05:46 <crc         > 
ACTION looks for a reference on this

2026-06-28 22:06:40 <crc         > https://www.ultratechnology.com/okad.htm and https://www.ultratechnology.com/mofe16.htm#tings