2025-12-16 01:04:32 !uptime 2025-12-16 01:04:32 352h 5min 3s 2025-12-16 21:38:53 Is there a way to always compile the interpreters input in gforth? I'm running various one liners that have ifs and loops and its annoying having to define and execute a word each time I write a new line 2025-12-16 21:52:55 Scrambled: I guess that is why everyone _needs_ his own implementation. 2025-12-16 21:57:44 I tried writing my own... 2025-12-16 22:08:23 Scrambled: Most Forth systems interpret (and compile, for that matter) word by word. When the compiler sees IF, it compiles a jump instruction, but it doesn't know what the jump target is yet, so it saves information on the stack indicating where the jump target needs to be put when it becomes known. Then, later, THEN says "Ah, this is where the jump needed to go to," so it scoops that address 2025-12-16 22:08:25 info off of the stack and stores the target address there. 2025-12-16 22:09:49 All of the other control constructs operate in a similar way, though if the jump goes at the end of the thing it works the other way around. If you think about this a little, you'll see that this just can't possibly be done if you're interpreting. An IF/THEN that could be interprted would have to work in an altogether different way, with flags that would indicate "don't execute this - it's in an 2025-12-16 22:09:51 IF we're hopping over" and so on. Most systems just don't bother. 2025-12-16 22:10:37 There are a few systems that will compile your whole line without executing anything, even in interpreted mode, in some temporary location, and then when it sees you hit Enter it executes that. Those systems could have IF/THEN in interpreted mode too, since in a sense it's always compiled. 2025-12-16 22:10:53 That's pretty rare, though - I'm only sure I've seen one, but there could be two or three I guess. 2025-12-16 22:11:40 I don't put the standard control structures in my systems anymore - I do everything (conditionals, loops, etc.) using conditional return primitives. 2025-12-16 22:12:16 Thats exactly what I'm looking for, a bit weird that its rare since it seems to me that it would be simpler to just compile everything 2025-12-16 22:12:25 Of course, they are compile only words - if you just typed one of them into the interpreter you'd crash your system. 2025-12-16 22:12:38 Give me a minute - I'm trying to recall to mind the name of that system. 2025-12-16 22:13:18 No pressure, just thought I'd save me some typing if there was a ready made solution in gforth 2025-12-16 22:13:36 It may be one of the ones Hans Bezemer did. 2025-12-16 22:15:07 You could probably write a little tool in GForth that would do that for you. 2025-12-16 22:15:36 Hmmm. That's a fun little idea. I may give that some thought too. 2025-12-16 22:15:45 If I get it to work I'll hand it off to you. 2025-12-16 22:16:55 Thanks! that'd be really cool 2025-12-16 22:17:45 KipIngram: FreeForth (http://christophe.lavarenne.free.fr/ff/). Perhaps even LaForth (https://www.forth.org/Ting/LaForth/index.html). 2025-12-16 22:20:45 Scrambled: It's an interesting question. IMO even a mistake. It is not even a question in Lisp, so why should it be in Forth? 2025-12-16 22:29:21 Is there a difference between compiled and interpreted lisp? I've never dug too deep into a lisp implementation but I'd imagine that there'd be no difference 2025-12-16 22:30:00 Well, I think the desire to use things like IF/THEN in little test snips is a valid one. It would only be a small saving of effort, but a little nonetheless. Now that it's been brought up it's fallen into the "intellectual puzzle" category for me. :-) 2025-12-16 22:31:25 I think it's not so much a "little tool, though - now that I think about it - as "writing a replacement interpreter." 2025-12-16 22:32:10 It would have to call QUERY (if that's how GForth even works - I don't know for sure), parse the words, find them, compile them to a buffer, etc. 2025-12-16 22:32:46 So maybe not "simple and clever" enough to be the sort of puzzle I was hoping for. Certainly it COULD BE DONE, but it might wind up feeling kind of brute force to me. 2025-12-16 22:33:22 I thought of just wrapping the whole interpreter string in a ": ;" pair 2025-12-16 22:34:15 Seems like nested definitions don't work though 2025-12-16 22:35:12 No, it would go deeper than that. You'd have to have a word that fetched a line from the keyboard - as data, and then processed it. 2025-12-16 22:35:27 I'm not sure how GForth's interpreter works; I'm most familiar with older more traditional ones. 2025-12-16 22:36:12 Something like : quit begin rp0 @ rp! query interpret again ; 2025-12-16 22:36:38 rp0 @ rp! clears the return stack. Query gets a line of text into the text input buffer, and interpret processes it. It just loops forever. 2025-12-16 22:37:42 Interpret loops over the words, checks the compile/interpret state tand the immediate bit and either interprets or compiles. It either checks for the end of line and breaks its loop, or else treats the end of line null like an actual immediate word and it breaks the loop when it executes. 2025-12-16 22:37:49 I always do it the latter way. 2025-12-16 22:38:43 I left a little out - after interpret returns it usually checks for stack overflow or underflow, does the ok promt, etc. - little housekeeping things like that. 2025-12-16 22:38:51 prompt 2025-12-16 22:40:05 Running "see quit" outputs pretty much what you've written, which is cool to see 2025-12-16 22:41:39 I've always found it fun that that lives in QUIT. Since it clears the return stack, you can run quit from anywhere, even deep down in your code, and it's fine - it just tosses all the junk and gives you a clean slate to carry on with. 2025-12-16 22:41:54 Return stack junk, that is - it keeps the data stack in case you want to inspect it. 2025-12-16 22:42:18 In older systems there was WARM which cleared the data stack and then ran QUIT. 2025-12-16 22:42:47 And COLD, which did a complete system restart - as though you said BYE and restarted it. 2025-12-16 22:44:29 The loop inside INTERPRET will use WORD to parse successive words out of the line you got from QUERY, then FIND to hunt for that word. If it finds it, then it interprets or compiles - if it doesn't it will attempt a number conversion. If that fails too, it throws an error, which says some stuff to you and QUITs. 2025-12-16 22:45:22 If STATE is 0, or if the word is IMMEDIATE, it gets executed. If neither of those things is the case it gets compiled. 2025-12-16 22:45:37 And that's about all there is to it.