2024-04-11 11:16:24 why? KipIngram 2024-04-11 11:59:45 assembly gives a lot more freedom in implementing things. Using a HLL will bring along baggage that may make some things more difficult to implement. 2024-04-11 13:27:02 right but there are languages such as C/C++ or even Rust that doesn't bring along any baggage, plus they will be light years more ergonomic than asm, still let you to do low level stuff? 2024-04-11 13:36:00 I'm trying to validate your point, but the test program in rust is still compiling ;p 2024-04-11 13:36:24 I've also tried to add tail recursion to the C test program, but I've corrupted the stack 2024-04-11 14:01:24 baggage in terms of ABI, restrictions on register access and such 2024-04-11 15:44:11 c/c++/rust do bring baggage. you're just not used to thinking about it because you usually take it for granted. 2024-04-11 15:44:43 i think the most immediately obvious one would be: how do you implement the forth dictinoary? 2024-04-11 15:53:14 Hello, quick vocabulary question: in forth do we write statements or expressions? what's the difference? 2024-04-11 15:59:21 looking at the proper def seems to say an expression has a value and a statement carries a task. So I guess colon definition for instance are statements. 2024-04-11 16:00:38 i would say these terms don't apply to forth 2024-04-11 16:01:11 What terms applies then? "sentences"? 2024-04-11 16:01:32 I'd agree with zelgomer; there's not a clear distinction in forth for these 2024-04-11 16:01:46 I know of words, dictionary, values, constants 2024-04-11 16:01:58 also, in c-like languages where i typically see these terms used, they are not mutually exclusive. x[1] = y + 3; is a statement comprised of a couple of expressions. 2024-04-11 16:02:24 constants and values may be words 2024-04-11 16:03:20 I am taking a little break from my vm and trying to create a tree-sitter for a forth-like language, trying to use the proper terminology when it comes to defining the grammar 2024-04-11 16:03:42 crc: I understand that everything is a word in forth 2024-04-11 16:04:23 I am just trying to define the sub-categories, like "colon definition", "stack comment", "comment" etc... 2024-04-11 16:04:54 but those things, I am currently calling them "statements" 2024-04-11 16:06:56 nature: the challenge you will face with forth is that the grammar is not fixed. new words can be defined which extend the grammar. 2024-04-11 16:08:17 S" and ( and \, for example, are often defined as colon words. if you can write a colon word to add new syntax, how can you possibly define this? 2024-04-11 16:08:48 Of course, I know this will not be perfect, it's on a best effort basis, and I am doing it to take my mind of the vm for a bit 2024-04-11 16:10:19 when i first got into forth, i lost a good amount of time trying to perfect a vim syntax file for my special flavor of forth. eventually it occurred to me that it was a pointless chore, and now i just forgo syntax highlighting entirely when i edit forth :) 2024-04-11 16:11:36 a forth like retro, which uses sigils, would be easier to parse, at least for the standard sigils 2024-04-11 16:24:34 if I parsed source into a tree, it might look similar to https://forth.works/temp/parsed.txt 2024-04-11 16:25:40 nice! 2024-04-11 16:27:06 I think you're right token-based forth are more well-suited for parsing and doing all sorts of fun stuff with a syntax tree 2024-04-11 16:28:13 I read on reddit the other day that you may be a bit more limited in terms of creating defining and parsing words with such a forth, did I understand correctly? 2024-04-11 16:30:52 referring to this thread: https://www.reddit.com/r/Forth/comments/oeq3jc/what_was_the_rational_behind_retroforth_having/ 2024-04-11 16:33:04 that's more due to some quirks in how retroforth's i/o was implemented. My smaller system, konilo, also is token based & uses sigils, but supports parsing. 2024-04-11 16:34:05 Do you think there is any drawbacks/limitations for token based forths? 2024-04-11 16:35:36 With a design like I use, a tiny bit of naming flexibility. Since I check sigils before doing dictionary lookups, word names that start with a sigil character won't be usable without workarounds 2024-04-11 16:35:47 I've been studying early adding machine architectures recently, and I'm struck by how there's stuff going on there that's similar to proramming. It's like the teeth on the gears are instructions in a program, and in fact it's like carefully synchronized multi-thread proramming - there are multiple wheels turning, and for the carry and borrow stuff the activities in the various digits have to be carefully 2024-04-11 16:35:49 synchronized so that the carry ripples properly. Turning the handle around once "runs all the threads,' and those teeth all come by their important points at just the right time. 2024-04-11 16:36:20 Don't know why I can't seem to get the g into programming this morning. 2024-04-11 16:36:26 KipIngram: did you like that automata documentary? :P 2024-04-11 16:36:42 Yes, though I found it a little overloaded with "social innuendo." 2024-04-11 16:36:50 Technical content was fantastic, though. 2024-04-11 16:36:57 veltas says the innuendo is a Brit thing. 2024-04-11 16:38:13 It amazes me that the accomplished all that stuff back then. The labor factor in it strains my mind even to consider. 2024-04-11 16:38:56 Well, they weren't distracted by the Internet 2024-04-11 16:39:03 :-) 2024-04-11 16:49:05 nature> Do you think there is any drawbacks/limitations for token based forths? 2024-04-11 16:49:08 complexity 2024-04-11 16:52:22 How is it more complex? 2024-04-11 16:53:10 'sup KipIngram :) Taking a mini-break from my vm, where you able to have a look at the opcodes I made? 2024-04-11 17:22:58 nature: because the alternative is to just delimit words by whitespace. it doesn't have to have a state machine to keep track of what's accepted as part of the current token and what begins a new token. 2024-04-11 17:25:26 my tokens are jut w 2024-04-11 17:25:32 just whitespace delimited 2024-04-11 17:25:59 then i guess i don't know what "token-based" means in this context 2024-04-11 17:30:26 in my systems, I don't generally make use of parsing words, so each whitespace delimited unit is processed independently. 2024-04-11 17:31:57 parsing words like s" add additional context that has to be tracked. 2024-04-11 17:34:43 nature: a drawback is a need to do some work on things like strings. I use a scheme where I replace underscores with spaces. e.g., 'hello_world 2024-04-11 17:47:25 I've always taken "token based" to mean that the "instructions" in the program aren't machine code and aren't addresses. So they would be indexes into a jump table or something like that. 2024-04-11 17:47:53 Whereas direct and indirect threaded make definitions out of address lists, and subroutine threaded just has machine code. 2024-04-11 17:47:57 that's token threaded, but the conversation at hand is about parsing 2024-04-11 17:48:35 Oh, parsing tokens. That's just some "representation" for keywords and so forth. 2024-04-11 17:48:47 Something you can handle easily in the machine. 2024-04-11 17:48:56 "not a long string" 2024-04-11 17:49:22 i would prefer to hear a definition from nature 2024-04-11 17:49:52 Me too, actually. 2024-04-11 17:49:53 i know what i think token-based means. the miscommunication is in what does nature think token-based means. 2024-04-11 18:11:32 Sorry, I was afk, so yeah by token based I meant something like retro or colorforth, where your words are a kinda "pre-parsed", like hints for the compiler. 2024-04-11 18:12:04 And no I didn't mean token threaded indeed 2024-04-11 18:14:32 Need to be afk some more, be back in a bit 2024-04-11 18:33:35 so you mean parsed into some intermediate representation before it's evaluated? do retro and colorforth do this? 2024-04-11 19:50:52 i wish i could decide on how to name things 2024-04-11 19:57:57 often a topic for writers (and coders) 2024-04-11 20:07:39 zelgomer: colorforth stores code in a preparsed format (see https://colorforth.github.io/parsed.html for some details); retroforth does not do this, though the sigils do serve as hints to tell the system how to treat words 2024-04-11 20:08:50 thanks, i didn't know that about color forth 2024-04-11 20:10:54 Yes that's what I mean, also in retroforth I guess the "pre-parsing" is more conceptual, but it still requires the programmer to hint the compiler with the role of a certain word 2024-04-11 20:15:34 crc: Does retroforth still need a compiler/interpreter state? 2024-04-11 20:16:46 Because an advantage of those token based like colorforth is that you don't need a compiler state anymore and basically green means compile the word et yellow mean execute it (like an immediate word) 2024-04-11 20:19:47 And tell me if I am wrong, but in theory nothing should prevent you from defining words like S" if you wanted right? 2024-04-11 20:20:31 nature: yes, I still have compiler/interpret state 2024-04-11 20:23:58 And one more question (sorry for asking so many, thank you for taking the time to answer!), do you have some doc on how you deal with quotes implementation-wise, or if not where in the code is it? I am interested in how it works. 2024-04-11 20:29:33 I could define an s" type word pretty easily in konilo (see http://forth.works/share/2o6d2VCUEW.txt), it's harder in retro due to the input handling 2024-04-11 20:29:55 (input in retro can come from sources apart from the keyboard/redirection of the keyboard, and there's not a reliable way to cover this currently) 2024-04-11 20:33:39 http://forth.works/share/quotes.txt is the code that implements quotes in both konilo & in retro 2024-04-11 20:34:39 they're both in assembly for my pair of vm implementions (ilo for konilo, nga for retro) 2024-04-11 20:56:32 Thanks! 2024-04-11 21:03:37 http://forth.works/share/quotes2.txt has a little more explanation 2024-04-11 22:17:25 Thanks crc, that last one is very helpful!