2022-11-27 00:13:23 <KipIngram   > Huh.  So, I'm reading some of the conversations that were held and linked to from that "recognizer propoal" someone posted here the other day.
2022-11-27 00:14:09 <KipIngram   > One commenter even talked about having the standard call for the Forth number recognizer to recognize "standard constants" (from the C library), like WM_PAINT and so on.
2022-11-27 00:14:44 <KipIngram   > While I recognize the convenience of having that capability, it's hard for me to like the idea of being required to build it into a Forth.
2022-11-27 00:27:44 <KipIngram   > You know, I think I might incorporate one small bit of extra smarts into my ; word.
2022-11-27 00:28:32 <KipIngram   > Sometimes I end a definition with an unconditional jump back to the start.  So no (;) following that will ever be executed.  In those cases I try to remember to use [ instead, which will exit compile mode without compiling the (;).
2022-11-27 00:28:54 <KipIngram   > So in addition to the usual tail optimization that we put into our ; words, I'm thinking of covering that case too.
2022-11-27 00:29:21 <KipIngram   > Just note whenever I compile a word that can never be "passed by," and omit the (;) compilation if ; immediately follows.
2022-11-27 00:29:48 <KipIngram   > Same result - it would just spare me having to remember, and I think the ; looks slightly better too.
2022-11-27 00:44:05 <KipIngram   > I'm also think of changing the way I do those jumps back.  As it is now the target has to be an address corresponding to the "latest dictionary entry."  So if I want to jump back somewhere other than the start of a word, I put another label in there with : (or a temporary one with .: ).
2022-11-27 00:45:21 <KipIngram   > I'd keep the ability to just full on recurse, back to the word itself.   But instead of requiring a dictionary entry, needed only temporarily but forever taking up header space, I could just have a word that "marks" the current location.
2022-11-27 00:46:03 <KipIngram   > Words that create dictionary entries will set the jump target value, but this other new word (which would be immediate) would set it as well.  No actual dictionary entry required.
2022-11-27 00:47:40 <KipIngram   > Well, that's nothing new, is it?  I'm just re-inventing BEGIN
2022-11-27 00:48:07 <KipIngram   > I'm sure I'd use something shorter, though.  :-)
2022-11-27 03:28:59 <veltas      > KipIngram: This is exactly the problem with recognizers and all new forth200x stuff. It's not forthy or elegant enough for people to want to include it
2022-11-27 03:29:27 <veltas      > There clearly was a point where the committees just started preferring a new style with heavy reliance on execution tokens
2022-11-27 03:32:27 <veltas      > Like for example the TRAVERSE-WORDLIST ( xt wordlist -) word which is horribly named
2022-11-27 03:33:51 <veltas      > But also takes an xt ( nametoken - continue?)
2022-11-27 03:37:15 <veltas      > KipIngram: Do you not have a separate EXIT?
2022-11-27 05:12:41 <jackdaniel  > hey o/
2022-11-27 05:13:21 <jackdaniel  > when learning forth on linux, should I stick to gforth or there's another recommended implementation?
2022-11-27 07:24:40 <neuro_sys__ > jackdaniel: Depends on your approach. If you want to practice writing Forth programs, I recommend gforth. If you want to learn how forth works, stay away from gforth.
2022-11-27 07:24:57 <neuro_sys__ > s/to practice //
2022-11-27 07:26:05 <neuro_sys__ > gforth is forth on steroids, and is a bit too smart for my taste in how it does things. But it's great for writing forth programs. Just make sure you have 0.7.9, and not 0.7.3 (sucks).
2022-11-27 07:28:12 <jackdaniel  > neuro_sys__: and if I want to learn how forth works? should I attempt to implement one from scratch?
2022-11-27 07:28:19 <jackdaniel  > (thanks for answering)
2022-11-27 07:28:36 <neuro_sys__ > As for learning forth, after having done the classic reads like Starting Forth by Brodie, I recommend reading the Forth 79 standard (because of its small size), and then 83 and 94 standards respectively. The latter is quite big, I think a Forth shouldn't be larger than the 94 standard.
2022-11-27 07:28:54 <neuro_sys__ > jackdaniel: Yes, you should attempt implementing from scratch. It's hard to learn without doing.
2022-11-27 07:29:11 <jackdaniel  > alright, thanks!
2022-11-27 07:29:44 <neuro_sys__ > For that, the best resources are: Fig Forth Systems Guide, zen and eForth, Moving Forth article, and sample tutorial/minimalist forth implementations like Jonesforth and the similar.
2022-11-27 07:29:45 <jackdaniel  > I'm tinkering with ecl bootstrap environment and I thought that having a running environment very early would be cool (ecl is embeddable common lisp)
2022-11-27 07:30:22 <jackdaniel  > 
ACTION takes notes

2022-11-27 07:31:59 <neuro_sys__ > Fig forth group also released the source code for dozens of CPUs in early 80s (6502, Z80, 8086, etc.), the assembly listing for those were also very useful for me.
2022-11-27 07:32:16 <neuro_sys__ > jackdaniel: Isn't ecl by itself enough? Or do you just want to tinker with Forth as an alternative to ecl?
2022-11-27 07:33:07 <jackdaniel  > as I've said, I'm tinkering with the bootstrap environment; orignally ecl had a well defined common language runtime; I'm attempting to revive that
2022-11-27 07:34:27 <jackdaniel  > 
ACTION is simply pursuing his curiosity

2022-11-27 07:35:08 <neuro_sys__ > I'm not familiar with ecl, so I don't fully understand. It's just intriguing but also doesn't make much senes to me to mix lisp and forth on the same system.
2022-11-27 07:35:22 <neuro_sys__ > Forth by itself would be enough to have a working, programmable, interactive system.
2022-11-27 07:36:56 <jackdaniel  > I'm into the intriguing part :) I can elaborate what made me think about using forth here if you are interested in that
2022-11-27 07:38:38 <neuro_sys__ > Feel free to write if you have time, I check this chat, and logs every now and then. I was just curious if you want to have both lisp and forth on the same system somehow.
2022-11-27 07:39:38 <neuro_sys__ > (Even if I disconnect, I read the logs crc keeps, so don't mind if I get disconnected)
2022-11-27 07:40:11 <jackdaniel  > yes, I want to rearrange the core of ecl so it may host multiple languages
2022-11-27 07:41:42 <jackdaniel  > I've already separated some early parts of the system to make it more modular; having a working language at this stage would be a fun thing to have (especially that stacks are already in place)
2022-11-27 07:42:06 <jackdaniel  > s/working/working and interactive/
2022-11-27 07:42:42 <jackdaniel  > and I've wanted to get more familiar with forth for a long time, so it came to me as an interesting idea ot use it
2022-11-27 07:43:21 <jackdaniel  > originally ecl hosted both common lisp and prolog
2022-11-27 07:52:37 <neuro_sys__ > I see. I'll ramble and philosophize a bit. It took me a long time to realize some of these things, and I would like to write it down (although I may be delusional at this point, because I think Forth is a kind of sweet madness).
2022-11-27 07:53:58 <neuro_sys__ > There's a mental barrier around Forth caused by a cultural shift in programming that I have observed. It seems like for the modern mindset and a lot of newcomers, it is sometimes perceived as just a language interpreter, like an eval loop with control structures, and rpn syntax. That's easy, but that's not Forth (strictly speaking), but just a postfix interpreter.
2022-11-27 07:58:23 <neuro_sys__ > Originally Forth was meant to be a fully hosted system solution, where it still makes the most sense, I think. A Forth system provides the "OS", compiler, filesystem (or lack there of), the editor, etc. So it makes more sense when it sits on the system, at the bottom of everything else.
2022-11-27 08:01:16 <jackdaniel  > 
ACTION just lets neuro_sys__ know that he's listening ,)

2022-11-27 08:02:09 <neuro_sys__ > Also Forth is not a language strictly speaking (excluding the modern forth-likes that evolved a long way, like Factor). I think I realized this better when I read Chuck's A Problem Oriented Language essay. Forth doesn't define a syntax (RPN is just a natural consequence of how the machine works, not a language design choice). It's more like a macro assembler, so the same difficulties of writing assembly applies to wri
2022-11-27 08:02:10 <neuro_sys__ > (i.e. it's a PITA).
2022-11-27 08:09:48 <eris[m]     > is it really like a macro assembler?
2022-11-27 08:09:52 <jackdaniel  > that's really similar to how lisp and smalltalk were designed (language-as-an-os-wise)
2022-11-27 08:09:54 <eris[m]     > it doesn't really go with the machine
2022-11-27 08:10:10 <eris[m]     > it uses the stack rather than the registers :)
2022-11-27 08:14:13 <neuro_sys__ > I think the stack(s) is the simplest way to abstract away the machine dependent registers. So that you can write portable code without dealing with the register allocation (see: graph coloring).  The main reason I think Forth is a glorified macro assembler is this. Imagine you use a macro assembler, and you want to write portable code. How do you do it? The Forth way. You create a virtual instruction set implemented i
2022-11-27 08:14:13 <neuro_sys__ > machine (primitive word list), then you build the rest of your application using only those macro definitions (or subroutine calls). You also need to eliminate registers from your code, so there you have the stack for parameter passing.
2022-11-27 08:15:07 <neuro_sys__ > This is a great read btw: http://www.forth.org/POL.pdf
2022-11-27 08:16:15 <neuro_sys__ > Remember my disclaimer that I was going to ramble and philosophize :)
2022-11-27 08:19:08 <jackdaniel  > thanks, will read it when time permits
2022-11-27 08:27:06 <olle        > Hm
2022-11-27 08:58:43 <veltas      > neuro_sys__: The simplest way to abstract a machine's registers IMO is just 0-31 or whatever number
2022-11-27 08:59:11 <veltas      > And also the stack specifically makes it harder to allocate registers in a simple way
2022-11-27 09:02:50 <Zarutian_iPad> https://filippo.io/fakenews/ just has to be paired with a fake paywalled site andwe are golden
2022-11-27 09:04:29 <neuro_sys__ > Agreed with the first point, although probably needs more thinking on my part if completely true. As for the second, I have read, but didn't look into myself, that register allocation is an NP hard problem (may be easier for humans), and that's why plenty of bytecode code languages use stack based VMs.
2022-11-27 09:04:59 <Zarutian_iPad> regarding register based ISAs: isnt the register muxing taking up quite a lot of die space relative to the usual hw stack implementation?
2022-11-27 09:06:08 <neuro_sys__ > Ah I saw the mistake in my comment. It's simpler to "abstract away", doesn't mean simpler to use.
2022-11-27 09:07:18 <veltas      > Well it's still an interesting consideration
2022-11-27 09:08:58 <veltas      > Register allocation NP hard ... that doesn't sound right for simple RISC stuff but it is probably true for x86
2022-11-27 09:09:17 <veltas      > It's certainly not trivial, although I don't know how many compilers try for a perfect solution
2022-11-27 09:09:29 <veltas      > You can probably do quite well with dumb allocation schemes
2022-11-27 09:10:42 <Zarutian_iPad> oh no, x86 has eight registers? so just treat it like any accumulator with index register machine.
2022-11-27 09:12:00 <veltas      > A lot of instructions need special registers
2022-11-27 09:12:22 <veltas      > I.e. eax/ecx/edx/esi etc all have special purposes IIRC
2022-11-27 09:15:35 <Zarutian_iPad> and frankly x86 has too many addressing modes and instructions
2022-11-27 09:17:01 <veltas      > Yes it's not very orthogonal
2022-11-27 09:22:44 <Zarutian_iPad> this is why I like excamera J1 design quite a bit
2022-11-27 09:26:17 <neuro_sys__ > I am thinking out loud the CPU abstraction for, say, add (+) operation with stack vs register approach. The Forth way (e.g. 1 2 + ) we already know, it needs a data stack. How would it look like for the register based approach? Let's say, as an example, there would be r0 and r1 for parameter passing. Then it would look like: r0 1 r1 2 +. r0 and r1 would be parsing words (parse the next token) that assigns to physical
2022-11-27 09:26:17 <neuro_sys__ > would be now much simpler to implement (and execute faster).  Okay, I just realized you don't need the words r0 and r1. You can still have the same "syntax" 1 2 +, but when the outer interpreter sees a number (1 and 2), it stores the parameters in a virtual array of registers. But wait! That's already a stack (or a queue)! It sounds like the only way to abstract away the registers is either a FIFO or a LIFO array. And
2022-11-27 09:33:30 <neuro_sys__ > So a LIFO (stack) is basically an array of infinite (theoretically) registers.
2022-11-27 09:34:51 <eris[m]     > yes, if you can PICK
2022-11-27 09:35:01 <eris[m]     > registers are used for more than just passing parameters
2022-11-27 09:35:36 <eris[m]     > also, you dont need to abstract away registers when writing portable code
2022-11-27 09:35:39 <eris[m]     > that's what you want to do
2022-11-27 09:36:17 <eris[m]     > Dis (the inferno VM), for instance, is a register machine
2022-11-27 09:36:31 <Zarutian_iPad> eris: I thought registers were only used to pass parameters to operations
2022-11-27 09:36:36 <neuro_sys__ > I think you could also limit the number of data elements you can pass to the physical number of registers on the machine (say only 8 elements for an x86), this way you wouldn't have a data stack at all, because all the parameters would be directly assigned on the registers by the outer interpreter. Although I think now you need to decide which registers to be used in subsequent "add" instructions for example (e.g. 1 2
2022-11-27 09:37:00 <MrMobius    > x86 has 16 registers in the x64 version. also,  there are simple algorithms for register allocation
2022-11-27 09:37:06 <eris[m]     > Zarutian: registers are used for temporary storage or for constants
2022-11-27 09:37:12 <neuro_sys__ > I think Chuck did this, i.e. in some of his Forth there was no data stack, because it was all mapped to physical registers (I can't remember which one, I guess not colorForth).
2022-11-27 09:37:26 <eris[m]     > and they are used for passing operands
2022-11-27 09:37:51 <eris[m]     > forth only has parameters to operations
2022-11-27 09:37:54 <eris[m]     > not operands to instructions
2022-11-27 09:38:00 <eris[m]     > parameteres to procedures
2022-11-27 09:39:32 <eris[m]     > most codegen already has another way to emulate an infinite set of registers: SSA
2022-11-27 09:40:55 <neuro_sys__ > It's true that you can utilize registers as constants for performance gain (there's I can't see any other reason why you would this). But the Forth is also meant to be used with inline assembly for such optimization needs. Define a code word, and use your registers for whatever ingenious optimization tricks you wish.
2022-11-27 09:41:45 <Zarutian_iPad> I am still on the opinion that register based isas are inherently slower and harder to make fast than dual stack machines
2022-11-27 09:43:44 <neuro_sys__ > I'm not knowledgable enough to attest to that, but I would agree with that if I had to bet on it. The only counter argument I can think of is the out of order execution (instruction level parallelism).
2022-11-27 09:43:44 <MrMobius    > the extra registers arent just used for holding constants. when you have a lot of registers that can do anything, you dont have any stack juggling to get the values you want to work on to the top of the stack
2022-11-27 09:44:12 <neuro_sys__ > MrMobius: Ever experienced register juggling? :D But yeah, I see what you mean.
2022-11-27 09:44:35 <MrMobius    > Forth essentially it into an accumulator machine with only one register. there is no way to have anything other than TOS be an adder or whatever else you want to do to calculate
2022-11-27 09:45:40 <neuro_sys__ > I think stack juggling is a programmer mistake. Programmers juggle with everything when first faced with a paradigm: juggling with polymorphism, juggling with microservices, etc. :P
2022-11-27 09:45:51 <MrMobius    > there is less register juggling when you have 16 general purpose registers than in forth where you have one general purpose register as TOS :)
2022-11-27 09:47:07 <neuro_sys__ > (I see the problem with my last statement now. There's just no easier way to avoid juggling in some problems. Avoiding the stack juggling is possible, I believe, but just not easy)
2022-11-27 09:47:17 <neuro_sys__ > s/juggling/stack juggling/
2022-11-27 09:47:25 <Zarutian_iPad> out of order execution only makes sense when you have instructions that have lots of microops needed to implement them and long value-propagation delays
2022-11-27 09:47:32 <MrMobius    > no, stack juggling is unavoidable in a straightforward forth. you just have to eat the massive performance loss unless youre willing to optimize and generate machine code
2022-11-27 09:48:08 <MrMobius    > and as I constantly repeat, I am not saying any of this to say you shouldnt use forth. im just being honest about the tradeoff. if that works for you, no reason to stop using forth!
2022-11-27 09:49:31 <neuro_sys__ > "stack juggling is unavoidable". I am curious if this can be proven. I feel like in my experience you can often arrange the data flow in a way to remove stack juggling (or at least reduce it significantly). I guess the quintessential example for this would be writing a word that finds the cubic polynomial determinant without using any variables. Now I feel like giving it a go.
2022-11-27 09:50:29 <neuro_sys__ > (Note, DUPs shouldn't be considered juggling :P)
2022-11-27 09:51:00 <neuro_sys__ > Here's a challenge : b^2-4ac ( a b c -- n ) ( todo ) ;
2022-11-27 09:51:17 <MrMobius    > how would you write this in Forth without stack juggling: if (a==5) b=7; else c=9;
2022-11-27 09:52:30 <Zarutian_iPad> like this A @ 5 = IF 7 B ! ELSE 9 C ! THEN
2022-11-27 09:52:45 <MrMobius    > assume a, b, and c are on the stack
2022-11-27 09:53:13 <MrMobius    > although I will note the variable version is dramatically slower than the machine code version too
2022-11-27 09:53:21 <Zarutian_iPad> the your b and c labels make no sense
2022-11-27 09:53:44 <Zarutian_iPad> the varaibles arent on the stack, the values are
2022-11-27 09:53:53 <neuro_sys__ > Yeah I didn't understand the example. Or do you talk about my b^2-4ac example?
2022-11-27 09:54:13 <neuro_sys__ > Does b=7 mean change the second element on the stack to 7?
2022-11-27 09:54:43 <MrMobius    > no, im using my own example. an experienced forth programmer would keep a, b, and c on the stack if possible and avoid variables unless necessary
2022-11-27 09:54:58 <neuro_sys__ > I suppose you expect ( a b c -- a b c ), and b c will be changed according to the value of a.
2022-11-27 09:55:08 <MrMobius    > so assuming the code is simple enough that we are just going to use the stack and not named variables, how would you do it?
2022-11-27 09:55:34 <neuro_sys__ > Well, that sounds exactly like a problem that Forth says: "don't solve it"
2022-11-27 09:56:31 <MrMobius    > whats the alternative then? this is a programming statement from week 2 of CS 101. im trying to make this as simple as possible
2022-11-27 09:57:30 <MrMobius    > ie this is functionality youll need in any program beyond a toy example
2022-11-27 09:57:30 <neuro_sys__ > Joking aside, I don't understand the problem, even though I see what you mean, which I think b^2-4ac is still a better and more realistic example for that. I don't understand what if a == 5 then b is 7 and c is 9 trying to solve.
2022-11-27 09:57:37 <veltas      > I think what MrMobius is asking is quite reasonable
2022-11-27 09:58:36 <veltas      > Forth is quite unergonomic at a lot of very simple solvable things that are trivial in e.g. C, especially when it comes to maths or anything with a lot of variables
2022-11-27 09:58:42 <veltas      > It is what it is
2022-11-27 09:59:08 <MrMobius    > neuro_sys__: sorry for the confusion. i didnt mean this in relation to your equation. im illustrating the problems with stack juggling and why you lose so much performance
2022-11-27 09:59:20 <neuro_sys__ > You know the idea that you understand the problem, and change the problem if possible to make it easier to solve. With such formal/imaginary problems, it's difficult to do that. In that case, Forth is not the right task for such problems (Lisp is far more suitable for that having been designed and defined formally from the get go).
2022-11-27 09:59:34 <MrMobius    > that is not an answer
2022-11-27 09:59:59 <MrMobius    > you cant hand wave your way out of the simplest programming statements
2022-11-27 10:00:00 <veltas      > if (a==5) b=7; else c=9;    ( a b c) 2 PICK 5 = IF NIP 7 SWAP ELSE DROP 9 THEN
2022-11-27 10:00:21 <veltas      > Something like that?
2022-11-27 10:00:25 <thrig       > : you-dont-need-to-see-his-papers ( ... ) ;
2022-11-27 10:01:11 <veltas      > I personally would just use variables though
2022-11-27 10:01:29 <veltas      > Which of course is still 'bad' compared to C because I'm already making it thread-unsafe etc
2022-11-27 10:01:37 <veltas      > But it really depends on the problem
2022-11-27 10:01:51 <MrMobius    > veltas: ya though I was just thinking of a single statement not a whole word. ie: 5 = IF DROP 7 ELSE NIP 9 SWAP THEN
2022-11-27 10:04:20 <MrMobius    > variables or the stack are both fine. i might do either of those too. the point is just you end up spending more cycles on overhead than calculation which you dont have to worry about on a register machine
2022-11-27 10:04:37 <veltas      > Local variables are fine though, so you could do  A 5 = IF 7 TO B ELSE 9 TO C THEN
2022-11-27 10:04:47 <MrMobius    > yep thats a good way too
2022-11-27 10:05:39 <veltas      > If you have full optimisation and data flow analysis I would expect it to not hurt using the stack, or locals etc
2022-11-27 10:05:50 <veltas      > But then you might as well use C or LLVM because you've made it so complicated
2022-11-27 10:06:08 <veltas      > At that point we wonder why we bother with a RPN language
2022-11-27 10:07:08 <veltas      > The whole point and power of forth is in having a relatively useful programming language you can realistically write or modify on any platform, with even some cool meta features to boot
2022-11-27 10:07:28 <MrMobius    > agreed. you just have to be honest about advantages and speed is not one of them
2022-11-27 10:07:32 <MrMobius    > the other parts are cool though
2022-11-27 10:07:45 <veltas      > It's an advantage compared with some other interpreted languages
2022-11-27 10:07:48 <thrig       > speed? folks use bash
2022-11-27 10:07:49 <veltas      > It's not an advantage vs C
2022-11-27 10:08:29 <MrMobius    > thrig: ya probably doesnt matter on x86. probably faster than python too. it matters in embedded or when youre trying to run on the same battery for a whole year
2022-11-27 10:08:37 <veltas      > Forth is quite fast for a simple language, i.e. my Forth is way faster than the BASIC built into the ZX Spectrum and it's not even a 'fast' forth, it's tokenised
2022-11-27 10:08:57 <veltas      > It matters when you have like a few KB to write your code in
2022-11-27 10:10:30 <MrMobius    > potentially. my tokenized forth on 6502 is about 40x slower than assembly so probably still faster than BASIC too
2022-11-27 10:11:24 <neuro_sys__ > MrMobius: I'm not handwaving. I just couldn't explain the gist of my answer and reasoning. Here's an example of what I mean: https://gist.github.com/neuro-sys/629441998e558279152df673789be5f7
2022-11-27 10:11:29 <veltas      > What's interesting about 6502 is that a LOT of stuff for 6502 even in assembly essentially runs a VM to make up for how verbose the arch is
2022-11-27 10:11:46 <veltas      > But that is rare, 6502 is an especially weak arch, a product of its time
2022-11-27 10:11:58 <thrig       > registers? pffft
2022-11-27 10:12:47 <MrMobius    > neuro_sys__: why do you think the real problem is a different one? can you honestly say that the real problem will never be solved by the piece of code I gave?
2022-11-27 10:13:00 <neuro_sys__ > As an extension to the above example, I mean that stack juggling is usually the result of "formal thinking".
2022-11-27 10:13:25 <MrMobius    > veltas: there is some VM stuff like SWEET16 but i think most of it is just assembly. i dont think it's a weak arch though for an 8 bit machine
2022-11-27 10:13:39 <veltas      > Just my opinion
2022-11-27 10:13:46 <neuro_sys__ > MrMobius: I already said that honestly. It cannot be solved with Forth without stack juggling, you can use a more appropriate language for that (I gave Lisp as a nice example I think that fits the formal problems).
2022-11-27 10:13:48 <MrMobius    > no worries :)
2022-11-27 10:14:34 <thrig       > LISP can be hilariously slow
2022-11-27 10:14:38 <neuro_sys__ > I think Forth is about avoiding solving imaginary problems, otherwise it would have an infix parser, as an example.
2022-11-27 10:14:44 <MrMobius    > neuro_sys__: it has nothing to do with formal problems. pick anything at all forth is good at and a simple if statement setting two variables could easily be unavoidable
2022-11-27 10:15:43 <MrMobius    > which is fine. the point was just that you lose speed with forth for even the simplest piece of code and cannot think your way out of it or solve the XY problem to avoid it. if youre fine with the speed hit then go for it
2022-11-27 10:16:07 <MrMobius    > lots of things dont need to be as fast as possible. we have register machines for that :P
2022-11-27 10:16:40 <thrig       > OTOH firefox spinning up the cpu fans after displaying a table with about 30 rows and 3 or 4 columns ...
2022-11-27 10:17:00 <MrMobius    > hehe
2022-11-27 10:17:42 <eris[m]     > : b^2-4ac ( a b c -- n ) swap dup * >r * 4 * r> - ;
2022-11-27 10:18:00 <eris[m]     > oops
2022-11-27 10:18:21 <eris[m]     > oh, no, that works
2022-11-27 10:22:15 <veltas      > I would much rather do maths in C than lisp
2022-11-27 10:25:35 <neuro_sys__ > I have difficulty following the reasoning that concludes stack juggling is unavoidable. I'll have to think more about that (even though I have thought a lot about it in the past year(s)). My experience has been so far that stack juggling is often a programmer's mistake (i.e. my mistake). When I write forth code, I try to avoid stack juggling not because of performance only, but because it's an inefficient, and painful
2022-11-27 10:25:36 <neuro_sys__ > which also produces slow code. I can often design my words and their contract so that there's almost no or very little need for stack juggling. When it's an absolute necessity, I use variables. Writing code without variables (or persistent state) always is difficult even when you do it with, say, lambda calculus, or with pure functions in other languages.
2022-11-27 10:25:57 <neuro_sys__ > Restrincting yourself to stack with badly designed word contracts will inevitably lead to stack juggling.
2022-11-27 10:27:38 <neuro_sys__ > eris[m]: You can also change the order of elements in the stack if that helps. It doesn't have to be ( a b c ).
2022-11-27 10:28:09 <neuro_sys__ > Just because b is in the middle makes it more complicated than it should be.
2022-11-27 10:28:33 <neuro_sys__ > And there's no real reason why it should be the second parameter when you are solving quadratics.
2022-11-27 10:28:45 <MrMobius    > I agree that you can avoid a lot of juggling by designing the code well. What I'm saying is, some juggling is unavoidable unless you use variables. Either the reduced but unavoidable minimal juggling or using variables are both much, much slower than registers. I don't doubt that you write good code and eliminate the juggling. My contention is that despite your best efforts, the language is set up to waste tons of cycles that y
2022-11-27 10:28:45 <MrMobius    > don't lose on a register machine.
2022-11-27 10:29:06 <KipIngram   > : b2-4ac  ( a b c --n)  { s2 @ * 2 << negate s1 @ dup * + s2 ! 2 } ;
2022-11-27 10:29:20 <veltas      > I think you've made yourself clear MrMobius
2022-11-27 10:29:20 <KipIngram   > Stack juggling might be faster in this case, though.
2022-11-27 10:29:24 <neuro_sys__ > MrMobius: I agree.
2022-11-27 10:30:36 <KipIngram   > I guess technically dup is a stack manipulation.
2022-11-27 10:30:47 <neuro_sys__ > Except not completely with the part: "the language is set up to waste tons of cycles that you don't lose on a register machine" :)
2022-11-27 10:31:15 <MrMobius    > veltas: so I havent made myself completely clear :P
2022-11-27 10:32:04 <KipIngram   > I think one of the big advantages of Forth is that you don't copy stuff around all the time.  C would have to push a, b, and c to the stack from variables a, b, and c before you even started solving the problem, and then copy the result from the stack into whereever you were putting it.
2022-11-27 10:33:00 <neuro_sys__ > Also note that there's no requirement how stack words actually should be implemented. Same with how C would implement parameter passing.
2022-11-27 10:33:24 <KipIngram   > : b2-4ac  ( a c b -- n)  st*x x<>z * @ << - ;
2022-11-27 10:33:34 <KipIngram   > If you had the hp41c words I'm thinking about you could do that.
2022-11-27 10:34:28 <MrMobius    > KipIngram: those might be good words to add!
2022-11-27 10:34:35 <KipIngram   > It's just hurting yourself to start with to require that the parameters be a b c instead of something that has b in x to start with.
2022-11-27 10:35:10 <KipIngram   > Well, I used st<arithmetic> and rcl<arithmetic> words heavily when I used to use that calculator.
2022-11-27 10:35:22 <KipIngram   > And being able to store to and recall from the stack itself was great.
2022-11-27 10:35:47 <KipIngram   > You could also do so indirectly, where the stack regs had register #'s.
2022-11-27 10:36:10 <KipIngram   > The complication was that every time you did something the stack registers all changed, so you had to keep up with that using pencil and paper.
2022-11-27 10:36:31 <KipIngram   > That's what my { ... n } avoids.
2022-11-27 10:37:17 <KipIngram   > Actually my first solution was wrong; it should be -1 } at the end instead of 2 }
2022-11-27 10:37:36 <KipIngram   > 0 } would drop all of a, b, and c, but since we've put the result into s2 we want to keep it.
2022-11-27 10:38:08 <veltas      > I will say that even fortran, C etc look bad when doing *real* maths and big calcs
2022-11-27 10:38:24 <veltas      > Where you're doing stuff harder than multiplying numbers
2022-11-27 10:38:51 <veltas      > But doing basic linear calculations is quite typical of general programming problems
2022-11-27 10:39:01 <veltas      > So it's useful that they are optimised for that
2022-11-27 10:39:08 <veltas      > Whereas forth isn't really optimised for anything
2022-11-27 10:39:15 <veltas      > Same as lisp
2022-11-27 10:43:17 <neuro_sys__ > I wonder if anyone has used Brad Rodriguez's BNF parser to implement an infix parser for doing algebra in Forth.
2022-11-27 10:45:40 <neuro_sys__ > The other day I had a look at CC64 (C compiler written in Forth for Commodore 64). It makes me think you could in theory use only the infix part to simplify your calculations.
2022-11-27 10:47:24 <KipIngram   > In that same book of Chuck's I mentioned last night, he also discussed a method involving what he called "levels" that made for a fairly simple infix processor.  I forget exactly how it worked, but each word had a "level number" that controlled when you actually did operations.  Sometimes you pushed things onto a "level stack" for execution later.  It was fairly simple and made good sense - I just don't
2022-11-27 10:47:26 <KipIngram   > remember it well enough to describe it here.
2022-11-27 10:47:34 <KipIngram   > But it solved the infix problem in a very direct way.
2022-11-27 10:47:57 <KipIngram   > The "level" basically kept up with the parentheses.
2022-11-27 10:48:12 <KipIngram   > Another idea from that book that apparently didn't catch on.
2022-11-27 10:48:37 <KipIngram   > I think when Chuck wrote that book he wasn't as dug in about the superiority of Forth and felt the need to show how you could do certain "common things."
2022-11-27 10:48:50 <KipIngram   > Whereas later he developed the "you shouldn't want to do that" attitude.
2022-11-27 10:48:52 <neuro_sys__ > KipIngram: Was that in POL, or which book?
2022-11-27 10:49:04 <KipIngram   > That sounds right.
2022-11-27 10:49:13 <KipIngram   > What did that stand for/
2022-11-27 10:49:18 <KipIngram   > No coffee yet this morning.
2022-11-27 10:49:20 <neuro_sys__ > BTW found this, looks interesting: https://www.complang.tuwien.ac.at/anton/euroforth/ef08/papers/haley.pdf
2022-11-27 10:49:23 <neuro_sys__ > : TEST ( -- n ) INFIX ( 3 * FRED / ( ( 3 + 5 ) / 2 ) ) ;
2022-11-27 10:50:18 <neuro_sys__ > By POL I meant the book Problem Oriented Language
2022-11-27 10:51:25 <KipIngram   > Yes, that's it.  I found it here just now;
2022-11-27 10:51:26 <KipIngram   > https://books.forth2020.org/home/forth-books/ch-moore-pol13
2022-11-27 10:52:20 <KipIngram   > He even says in there "people will say this language isn't any good, because it won't do infix.  But here's how it can.>>"
2022-11-27 10:52:28 <KipIngram   > God - can't type this morning.
2022-11-27 10:52:32 <neuro_sys__ > I like the part: "It offers no advantages over the operands-preceeding-operator and has some limitations. But people are accustomed to it and negatively-impressed by its absence. So I will show you how to provide the capability."
2022-11-27 10:52:43 <KipIngram   > right.
2022-11-27 10:52:51 <KipIngram   > He just stopped feeling that way later.  :-)
2022-11-27 10:53:02 <neuro_sys__ > Did he?
2022-11-27 10:53:24 <KipIngram   > Well, he stopped showing a need to "match up" with other languages.
2022-11-27 10:53:32 <KipIngram   > But I'm assuming - I never saw a quote to that effect.
2022-11-27 10:53:33 <neuro_sys__ > Ah you mean in that direction. Yes :)
2022-11-27 10:53:50 <KipIngram   > Makes sense - we're less secure in our ways when we're younger.
2022-11-27 10:54:14 <KipIngram   > Well, at least once we're old enough to realize the world's not as stupid as we first thought it was.
2022-11-27 10:54:29 <KipIngram   > When kids are really young they're always right.  :-)
2022-11-27 10:55:42 <KipIngram   > But I started using RPN freshman year at college, so I never doubted RPN.
2022-11-27 10:55:53 <neuro_sys__ > I also like the part: "How do we implement them? Well we don't." (although this is completley out of context, so I'm just kidding).
2022-11-27 10:56:04 <KipIngram   > Very much just became "the way a calculator should work" for me.
2022-11-27 10:56:26 <KipIngram   > Yeah - I've always been a fan of avoiding problems by design rather than solving them.
2022-11-27 10:56:47 <KipIngram   > Just make them not show up in the first place.
2022-11-27 10:56:49 <neuro_sys__ > I would rather do algebra in algebra syntax, and not having to convert that into RPN. But thankfully when writing programs, algebra is less than 0.1% of my problem space. If it was more, I would use an infix parser.
2022-11-27 10:58:12 <KipIngram   > See, that's the thing that's different with me.  I'm fine with writing things out in infix, the way they are in the physics books and so on, because that's the form the knowledge is delivered in.  But the minute I'm ready to calculate something, RPN is comfortable to me.
2022-11-27 10:58:47 <KipIngram   > I've seen essays on the notion that we COULD teach it all in postfix to start with.  Right from grade school.  The argument is that it would actually work better to just do it that way to begin with.
2022-11-27 10:59:12 <KipIngram   > Like instead of teaching kids that a+b = b+c, just teach them that a b + = b a +
2022-11-27 10:59:14 <KipIngram   > Etc.
2022-11-27 10:59:33 <KipIngram   > Of course, that's a pointless argument; the world ain't gonna change.
2022-11-27 11:00:30 <KipIngram   > I haven't thought about it enough to be willing to say "I'm sure they're right," but I have a fairly strong instinct they probably are.
2022-11-27 11:00:56 <KipIngram   > Maybe some boring vacation week I should work throught it, just to see how well it works.
2022-11-27 11:01:09 <KipIngram   > Take some introductory book and translate it.
2022-11-27 11:03:20 <KipIngram   > I think everyone develops a degree of postfix thinking without realizing it.  Almost anyone, faced with a*(b+c), will add b and c first when they pick up their calculator.  Though I've never used a fancy infix calculator with ( and ) keys.  Maybe they don't.
2022-11-27 11:03:50 <KipIngram   > I think I had my HP before infix calculators with ( ) keys became common.
2022-11-27 11:04:34 <KipIngram   > But may what I should claim is that at least a fair number of people would add first and then multiply, without even realizing they'd done anything postfixy.
2022-11-27 11:05:25 <KipIngram   > b + c * a works even on calculators without ( )
2022-11-27 11:05:53 <neuro_sys__ > Re: avoiding problems by design before I go for dinner. This is something I have learned before I came across Forth and Chuck's writings, just in regular work life. Change the problem. It's often possible. Because usually the problem assessment/requirements are defined wrongly. Change the presumptions (use different ones) to fit for the simplest possible solution. Make the problem simpler, and solve a simpler problem.
2022-11-27 11:05:53 <neuro_sys__ > is full of this mindset. A great example is the Forth's solution to a filesystem: BLOCK words.
2022-11-27 11:05:54 <KipIngram   > But that is a step toward postfix, even though it's not, fully.
2022-11-27 11:06:18 <KipIngram   > Yes!
2022-11-27 11:06:49 <KipIngram   > After all - you are the one being tasked with SOLVING the problem.  You should wind up understanding it better than the people who gave it to you do, so your job isn't JUST implementing.
2022-11-27 11:07:08 <KipIngram   > You're not just a translator from vernacular to explicit solution.
2022-11-27 11:07:47 <KipIngram   > Well, I also see BLOCK words as a necessary first step, even if you eventually want a file system.
2022-11-27 11:08:02 <KipIngram   > He talks a lot in that book about ways to manage your blocks, which are all baby steps toward a file system.
2022-11-27 11:08:18 <KipIngram   > Mostly chaining them into linked lists.
2022-11-27 11:08:37 <KipIngram   > Nothing terribly fancy, but it moves you up to regarding groups of blocks as "data entities."
2022-11-27 11:08:53 <neuro_sys__ > Academia and a certain kind of formal education prevents this though. Requirements are often considered sacred, immutable facts that cannot be altered in any way. For large groups organizing their work, immutable contracts are useful, but that leads to nonsensical beuracracy.
2022-11-27 11:09:14 <KipIngram   > Every language, at some level, has to regard disks as arrays of blocks, since... that's what they are.  Forth just exposes that level to you.
2022-11-27 11:10:56 <KipIngram   > Even on our ssds at work, the truly bottom interface (physical flash blocks) is hidden - we present it as an array of logical blocks, and compression and wear leveling stuff does a bunch of fancy footwork to handle the translation to physical.
2022-11-27 11:11:30 <KipIngram   > neuro-sys__: All very true.
2022-11-27 11:12:01 <KipIngram   > But not necessarily impractical; if you want to change the problem, you have to propagate those changes throughout the orgainzation, to people who may already have work complete and so on.
2022-11-27 11:12:16 <KipIngram   > There's definitely friction there when the team solving the overall problem is large.
2022-11-27 11:12:55 <KipIngram   > And chances are you will fail to propagate it to everyone, and then you have bugs.
2022-11-27 11:13:20 <KipIngram   > What usually happens, though, is that the requirements are not as complete as they thought they were.
2022-11-27 11:13:35 <KipIngram   > Even if they're all met, you can wind up with incompatible pieces.
2022-11-27 11:14:24 <KipIngram   > Which of course is why it's become bureaucratic, with people pushing for ever more stringent and well-specified requirements.
2022-11-27 11:14:49 <thrig       > wouldn't that make the spec too complicated?
2022-11-27 11:15:24 <KipIngram   > Sure, but sometimes they are.  That quote above is right about how specs are thought of in big outfits - they ARE regarded as sacred.
2022-11-27 11:15:57 <KipIngram   > I think requirements is a better word than spec.  I regard specifications as numerical quantities telling you how good the solution needs to be, not as constraints on how the solution is done.
2022-11-27 11:16:03 <KipIngram   > How fast does it need to go, etc.
2022-11-27 11:16:08 <veltas      > I think infix is fundamentally more natural and easier
2022-11-27 11:16:13 <veltas      > I don't think teaching RPN would help
2022-11-27 11:16:32 <KipIngram   > Even then the initial numbers are requirements too - you might wind up going faster and then the spec, published at the end and after testing, would reflect the real number and not the original target.
2022-11-27 11:16:34 <veltas      > Because related arguments are nearer to their operators
2022-11-27 11:16:55 <veltas      > You get visual indication of parameters and grouping
2022-11-27 11:16:59 <KipIngram   > I think we can't really know that without trying it on a batch of kids.
2022-11-27 11:17:02 <veltas      > The stack is just harder
2022-11-27 11:17:04 <KipIngram   > Which no one will ever do.
2022-11-27 11:17:12 <veltas      > I have given my rationale
2022-11-27 11:17:13 <KipIngram   > I think it toally depends on what you're used to.
2022-11-27 11:17:22 <KipIngram   > I never found it hard, once I was used to it.
2022-11-27 11:17:24 <veltas      > I don't rely entirely on empirical evidence, I think it can be reasoned that it's better
2022-11-27 11:17:28 <KipIngram   > You start to be able to picture it mentally.
2022-11-27 11:17:33 <KipIngram   > it's a learned skill.
2022-11-27 11:18:04 <KipIngram   > but - I'm saying that based only on my own personal experience, not on a sample that's significant.
2022-11-27 11:18:46 <KipIngram   > I agree - you might be able to work through it and show definitive reasons one or the other is better.
2022-11-27 11:18:57 <KipIngram   > Which leads to the fewest operations is one way.
2022-11-27 11:19:14 <KipIngram   > But once you drift over into "which is easier to learn," I expect it would vary from person to person.
2022-11-27 11:19:52 <KipIngram   > I think RPN *usually* requires fewer keystrokes on a calculator.
2022-11-27 11:19:57 <KipIngram   > But that's just one measure of goodness.
2022-11-27 11:20:45 <KipIngram   > And as the b2-4ac example indicates, the problem can just be given in a more or less obtuse way.  Setting the initial parameters a b c complicates the solution.
2022-11-27 11:21:19 <KipIngram   > And in that case reversing them doesn't help, since a and c are symmetrical in the solution.
2022-11-27 11:21:33 <veltas      > I think b*b-4*a*c is quite a lot more readable than forth
2022-11-27 11:21:38 <veltas      > You can believe what you want
2022-11-27 11:21:57 <veltas      > Forth is a lot of things, but I don't think it's good at algebra
2022-11-27 11:21:57 <KipIngram   > I will just point out that you grew up learning it that way.  And you can too (believe whatever you want).  :-)
2022-11-27 11:22:07 <KipIngram   > we are all very, VERY steeped in infix training.
2022-11-27 11:22:08 <veltas      > I've given my rationale for why I think infix is more natural
2022-11-27 11:22:17 <veltas      > I mean there is a reason why we use infix in our notation
2022-11-27 11:22:23 <veltas      > It's not just pure coincidence
2022-11-27 11:22:38 <KipIngram   > I just think it's hard to overstate the importance of how we are trained from childhood in determining what seems "natural."
2022-11-27 11:23:15 <veltas      > I know but you have to reason about it like for instance being able to group relevant details visually is not a nurture thing, it's nature
2022-11-27 11:23:22 <veltas      > Like they are either next to each other or not
2022-11-27 11:23:25 <KipIngram   > Every language in the world other than English seems "artificial and overly complex" to me, though I know the others are just as good and some of them better.
2022-11-27 11:23:39 <KipIngram   > But English is natural to me and always will be.
2022-11-27 11:23:57 <KipIngram   > I can't help it - even if I go learn 10 other languages.
2022-11-27 11:23:59 <veltas      > Maths is very simple and abstract so it's easier to make this kind of statement
2022-11-27 11:24:16 <KipIngram   > Well, we could argue all day about it.
2022-11-27 11:24:25 <KipIngram   > Likely neither of us will change his mind.
2022-11-27 11:24:26 <veltas      > I won't though :P
2022-11-27 11:24:34 <veltas      > I won't argue about it I mean
2022-11-27 11:24:46 <KipIngram   > No, not a good way to spend our day.
2022-11-27 11:24:47 <veltas      > I've stated my case, people will make up their own minds
2022-11-27 11:24:59 <KipIngram   > Yep.  Sounds like a plan.
2022-11-27 11:25:08 <veltas      > A good way to spend my free time is probably to carry on with bot-forth
2022-11-27 11:25:42 <KipIngram   > Well, I'm just trying to muddle through to Tuesday without my tooth hurting me too much.  Tuesday was the earliest my dentist could see me.
2022-11-27 11:25:47 <KipIngram   > Friday was... really bad.
2022-11-27 11:25:56 <KipIngram   > Yesterday and today so far better.
2022-11-27 11:26:06 <veltas      > Oh dear, sorry to hear that
2022-11-27 11:26:28 <KipIngram   > I made a mistake Friday of trying to eat a plate of Thanksgiving leftovers, and I think I compressed something in there, and it spent all day fighting back.
2022-11-27 11:26:41 <KipIngram   > I've resolved to live on soup until Tuesday.
2022-11-27 11:26:55 <veltas      > Ouch
2022-11-27 11:27:10 <KipIngram   > And at least that's better enought that I can do things like debate arithmetic.  :-0
2022-11-27 11:27:12 <KipIngram   > :-)
2022-11-27 11:28:36 <KipIngram   > Well, it's my own fault.  I've known I needed work on this for a good while, but it wasn't causing immediate pain, and I've exhausted my dental benefits for 2022 and was trying to make it to 2023.  But, it's not going to make it so I'll have to open my wallet.
2022-11-27 11:29:18 <KipIngram   > And of course it picks the onset of a holiday period to rear its head.  Worst possible timing.
2022-11-27 12:46:37 <KipIngram   > So, how has the handling of interpretation input evolved as the standards have unfolded?  In the old Forths most of my work is based on, there is a buffer for that, the tib, and QUERY puts a line of text there, and it's just assumed that's where it is by later words.
2022-11-27 12:46:47 <KipIngram   > Has this evolved toward something more stack driven?
2022-11-27 12:47:06 <KipIngram   > Obviously you need to have a tib somewhere in your system, but I kind of feel like the later words shouldn't just assume that's where they work.
2022-11-27 12:47:25 <KipIngram   > Like, I think QUERY should leave a string address on the stack, and INTERPRET should take one.
2022-11-27 12:47:31 <KipIngram   > What's the modern convention there?
2022-11-27 12:48:42 <KipIngram   > Having a system-wide >IN seems a little unwise too.
2022-11-27 12:49:23 <gordonjcp   > probably no point in changing that tbh
2022-11-27 12:49:42 <gordonjcp   > maybe I'm too much of a crabbit old bastard to understand these modern multiuser things
2022-11-27 12:49:45 <KipIngram   > Well, I think the downside is that if you put info to track that on the stack, you'd be covering up the stuff the user put on the stack.
2022-11-27 12:49:52 <KipIngram   > You are, after all, executing his input during all of this.
2022-11-27 12:50:00 <KipIngram   > That's probably what drives us away from it.
2022-11-27 12:50:17 <KipIngram   > There are certain ways the interpreter can't use the stack, because the user is using it.
2022-11-27 12:50:23 <gordonjcp   > is there a practical need for the TIB to be movable?
2022-11-27 12:50:34 <gordonjcp   > I mean, without just having a variable for it
2022-11-27 12:50:44 <KipIngram   > Well, I'm just thinking that executable input might come from all kinds of different sources.
2022-11-27 12:50:50 <gordonjcp   > mmm
2022-11-27 12:51:00 <KipIngram   > Maybe I want to say "Hey, interpret this string..."
2022-11-27 12:51:02 <gordonjcp   > like disk buffers
2022-11-27 12:51:23 <KipIngram   > Like, for example
2022-11-27 12:51:34 <KipIngram   > ." 1 2 3 . . ." interpret
2022-11-27 12:51:46 <KipIngram   > Oh, sorry.
2022-11-27 12:51:48 <KipIngram   > s"
2022-11-27 12:52:03 <KipIngram   > And we're right back to Forth weakness on strings.
2022-11-27 12:52:18 <KipIngram   > I actually remember now - I've been down this path.
2022-11-27 12:52:36 <KipIngram   > I tried to do this at one point, and was stymied by the fact that I couldn't leave system info on the stack across execution of input words.
2022-11-27 12:52:48 <KipIngram   > Stack's gotta be clean.
2022-11-27 12:53:07 <KipIngram   > Otherwise user types + and oops, you've got addresses and indices on top of his numbers.
2022-11-27 12:53:16 <thrig       > until they construct more pancakes, anyways
2022-11-27 12:53:32 <KipIngram   > Almost makes one wish there could be a "system stack" and a "user stack."
2022-11-27 12:53:47 <KipIngram   > Because the system really is like a separate process, overseeing the user's work flow.
2022-11-27 12:54:33 <KipIngram   > But I see speed bumps on that road already.
2022-11-27 12:55:30 <KipIngram   > Say system has its own stack, and it FINDs a user word.  xt for that word is now on system stack.  If system flips stack before running EXECUTE, it loses that xt.  If EXECUTE flips back and forth, then it becoems impossible to use it directly as the user.
2022-11-27 12:55:41 <KipIngram   > So - it's inelegant any way you try to come at it.
2022-11-27 12:56:47 <KipIngram   > We were talking earlier about making problems go away - you make this one go away by just not needing the stack for system operations.
2022-11-27 12:56:57 <KipIngram   > At least not "across user words.'
2022-11-27 12:57:17 <KipIngram   > So we just assume we KNOW where the input is, and so on.
2022-11-27 12:57:39 <KipIngram   > TIB could be a variable that points to the string.
2022-11-27 12:57:59 <KipIngram   > And then it would be straightforward to interpret some other string.  Just save tib value and restore it after.
2022-11-27 12:58:12 <KipIngram   > Like LOAD saves BLK.
2022-11-27 12:58:41 <KipIngram   > What you're really doing there is making BLK and >IN into pushdown stacks.
2022-11-27 12:58:45 <KipIngram   > Functionally.
2022-11-27 12:59:11 <KipIngram   > Because if you try to just have them on the stack througout, you run into these problems.
2022-11-27 13:01:19 <KipIngram   > Another possibility is to not have the globals, have them on the stack, but make sure you use >r and r> to move them out of the way at the right times.  Probably the globals make for shorter code, but I haven't carefully compared them.
2022-11-27 13:07:59 <KipIngram   > But the core requirement of any solution is easy to state: the interpreter must have the stack back to "user state" when it EXECUTEs the found xt.  Before and after it can do anything it wants.
2022-11-27 13:09:13 <KipIngram   > So certainly a series >r before and r> after would fix it up.  If you wanted to do it that way.
2022-11-27 13:10:06 <KipIngram   > Similarly, a word can do anything it wants with BLK and >IN, but better have them restored when it exits.
2022-11-27 13:10:55 <KipIngram   > Though, that set of >r before EXECUTE needs to leave the found xt there, since EXECUTE uses it.  It's the stuff BELOW THAT that the system put there that needs to be cleared out.  So it gets uglier.
2022-11-27 13:11:56 <KipIngram   > What this seems to beg for is a way to just park local data on the return stack, and use it without having to move it around item by item.
2022-11-27 13:12:05 <KipIngram   > Something like my frame words, only for the return stack.
2022-11-27 13:12:13 <KipIngram   > Unfortunately I don't have registers to spare for that.
2022-11-27 13:12:27 <KipIngram   > Maybe if I were on an ARM64 with 32 registers that would be the way to go.
2022-11-27 13:13:52 <KipIngram   > And yes, I recognize the irony of me talking about Forth on an x86_64 and at the same time complaining about "not enough registers."
2022-11-27 13:14:12 <KipIngram   > But I've just figured every step of the way, "those registers are THERE - I can use them to get better performance."
2022-11-27 13:14:24 <KipIngram   > And it's like money - first thing you know you hardly have any left.
2022-11-27 13:16:08 <KipIngram   > More than once the way they name the extra 64-bit registers, r8-r15, has led me to lament the fact that r0-r7 don't exist.
2022-11-27 13:16:19 <KipIngram   > Or, rather, they do but they have other names.
2022-11-27 13:17:20 <KipIngram   > I also find it annoying that there USED to be pusha and popa instructions, that pushed and popped all of them, but they took that away somewhere along the line.
2022-11-27 13:17:42 <KipIngram   > That just seems stupid to me - every processor is going to be asked to do context switches; there should be SOME instruction for doing that as fast as possible.
2022-11-27 13:19:26 <KipIngram   > I quickly wrote pushm and popm macros for my nasm source, but of course those are macros - all they do is make the source look tidier.
2022-11-27 13:24:30 <KipIngram   > Anyway, the way my system has evolved has one noteworthy shortcoming: I can't do nested loops within a single definition.  Unless they both happen to jump back to the most recent label.
2022-11-27 13:24:46 <KipIngram   > But I told myself I shouldn't want to - that is an opportunity to factor.  Put the inner loop in its own word.
2022-11-27 13:25:24 <KipIngram   > That's what I lose by not having the conventional words.
2022-11-27 13:26:03 <KipIngram   > So I'm at least giving though to reviving some of those, but with alterned names/details.
2022-11-27 13:26:36 <KipIngram   > Maybe BEGIN ... AGAIN becomes {: ... :}
2022-11-27 13:26:59 <KipIngram   > And then variations on that theme with conditionals prefixed to either {: or :} to get the related functionalities.
2022-11-27 13:27:12 <KipIngram   > IF ... THEN --> 0!={: ... :}
2022-11-27 13:30:35 <KipIngram   > BEGIN ... UNTIL --> {: ... 0=:}
2022-11-27 13:31:25 <KipIngram   > And, if desired...
2022-11-27 13:32:06 <KipIngram   > IF ... ELSE ... THEN --> 0!={ ... :}{: ... :}
2022-11-27 13:32:10 <neuro_sys__ > Reminds me of Z80's EXX instruction.
2022-11-27 13:32:49 <KipIngram   > Oh, yeah - that somehow related to dual register banks?
2022-11-27 13:32:58 <neuro_sys__ > 1 NOP, and all your registers are swapped. Good for interrupts task switching. :)
2022-11-27 13:33:23 <KipIngram   > Yeah.  Woudln't nest, but sure, for interrupts that's usually enough.
2022-11-27 13:33:35 <KipIngram   > If you do with ISR's what you should do with them.  :-)
2022-11-27 13:34:29 <KipIngram   > I guess you might worry if your interrupts were of wildly different priority - maybe you can't always postpone a new one until you're finished servicing this one.
2022-11-27 13:35:00 <KipIngram   > But I've always believed in getting the job done as quickly as possible and getting out of ISR's.
2022-11-27 13:35:15 <KipIngram   > The less you can have to do the better.
2022-11-27 13:37:02 <KipIngram   > Anyway, what I'd do with the above today would be to make each of those ...'s a word and use conditional returns appropriately.
2022-11-27 13:50:59 <neuro_sys__ > I just wrote a rudimentary type checker I had been thinking of, and it seems to be working. I even got the pointer to type thing work. For example: VARIABLE:INT A   A 1 + throws type mismatch error because A is of type INT&, whereas 1 is INT. The only problem is it's dynamic, and I can't easily make the type words immediate. Not sure how practically useful this would be, but together with T{ }T will probably help me r
2022-11-27 13:51:00 <neuro_sys__ > significantly. Not sure if it's worth the extra hassle of annotating every word with types though.
2022-11-27 13:52:22 <KipIngram   > Ok, so you're sort of declaring that you will never want to increment that address - it's the address of A CELL, and changing it would be an error?
2022-11-27 13:52:40 <KipIngram   > So an array address would be something different.
2022-11-27 13:52:54 <KipIngram   > And you'll regard indexing an array as "different from addition"?
2022-11-27 13:53:07 <neuro_sys__ > This is what it looks like for the overly simplistic test case: https://gist.githubusercontent.com/neuro-sys/3e34d795aef9e9ba10ec26d158a4276f/raw/55a4543c37f0322a5ef39b6eca5b1a93c36d42bf/gistfile1.txt
2022-11-27 13:54:03 <neuro_sys__ > KipIngram: I bet it will become very hairy quickly :) For incrementing an address, I would need to create an address incrementing word.
2022-11-27 13:54:19 <neuro_sys__ > I'm just playing around, it's most probably not worth it.
2022-11-27 13:54:50 <KipIngram   > Makes sense, and besides, you might want the index step to advance you by the size of one item.
2022-11-27 13:54:54 <KipIngram   > Not one byte.
2022-11-27 13:55:21 <neuro_sys__ > Actually need to fix my example to replace + @ and ! with type counterparts +int @int and !int. Otherwise those words won't work with other types.
2022-11-27 13:55:46 <KipIngram   > What I'm leaning to (someday - haven't done this yet) is that object on stack thing I mentioned.  A 64-byte stack cell would contain mostly address, but up in the high bits would be a type value.  So just by being on the stack that type info is there for each object.
2022-11-27 13:56:08 <KipIngram   > I'd use ot to steer word searches, so only words valid to run on that stack type pattern would be found.  So I could overload names at will.
2022-11-27 13:56:30 <KipIngram   > And the type would also select the method used to "index to the next array item" and whatever else came up.
2022-11-27 13:57:21 <KipIngram   > Arrays would live in that ropes structure, and system provided words would be used to step along an array; those would know how to recognize the need to use the rope tree to move to the next page of entries for an array that didn't fit in one page.
2022-11-27 13:57:42 <KipIngram   > As long as you knew you were within a page (for small things you knew would fit, for example), you'd be free to use the usual arithmetic methods directly.
2022-11-27 13:57:49 <KipIngram   > But it's on you to stay out of trouble doing that.
2022-11-27 13:58:03 <KipIngram   > For example, pages for strings might be 256 bytes.
2022-11-27 13:58:12 <KipIngram   > So most strings I ever deal with would "fit in one."
2022-11-27 13:58:25 <KipIngram   > But it would support very long strings - you'd use the system words to stride along them.
2022-11-27 13:59:01 <neuro_sys__ > I was thinking of something similar, but I'd use the dictionary entry to record the type information along with the word (or a separate dictionary area). I would prefer static type checking, so in runtime there's no overhead. Although that may be useful too in certain scenarios. For dynamic type checking, I believe using a separate type stack is cleaner.
2022-11-27 13:59:37 <KipIngram   > Yes - for mine too the word's header would call out its input stack requirements.
2022-11-27 13:59:51 <KipIngram   > The 'stack effect' would be codified in that sense.
2022-11-27 14:00:15 <KipIngram   > And that's how the compiler would track what the expected stack types would be at any point within compiling a definition.
2022-11-27 14:00:42 <KipIngram   > I'm not sure how easy that will prove to be.
2022-11-27 14:00:57 <KipIngram   > May expose a rat's nest of things to wrangle with.
2022-11-27 14:01:22 <KipIngram   > But if there's going to be any hope at all of the system actually working, the compiler has to have that capability.
2022-11-27 14:02:48 <KipIngram   > It would be easy enough to still be able to put plain ints on the stack - I'd just have that "type" be all zeros in the high bits.
2022-11-27 14:03:21 <KipIngram   > So I'd be giving up some range, and I'd  have to be careful with negative integers.  That might be problematic actually; I don't have a feel for how hard that would be to handle.
2022-11-27 14:03:39 <KipIngram   > Because working with small negative integers is not uncommon the way working with very very large positive ones is.
2022-11-27 14:04:23 <KipIngram   > Maybe I could identify all zero's and all 1's in the type field as the same type.
2022-11-27 14:04:51 <KipIngram   > I guess that would almost certainly make it easier.
2022-11-27 14:06:09 <KipIngram   > But then I could take the address of an ALLOTed memory block and "cast" it into an object just by setting the high bits.
2022-11-27 14:06:57 <KipIngram   > dovar for such objects would set that automatically when the object name was executed.
2022-11-27 14:07:45 <KipIngram   > It might make sense for the bits of the type field to carry particular information; like one of them might be the cell size for that object.
2022-11-27 14:08:06 <KipIngram   > one group that is.
2022-11-27 14:09:20 <KipIngram   > So what you would NOT be able to do is actually have a float's data "on the stack."  You need all 64 bits for the float value itself.  Nothing left for the type.  So floats would "live" somewhere else, and the stacked item would point to them.
2022-11-27 14:10:17 <KipIngram   > In the end it might work out better for the type field to just be a labeling integer, and there would be a table of type data for the various type items.
2022-11-27 14:11:19 <KipIngram   > So that pointer to a float might point to.. a float.  And it would be invalid to increment the address part.  Or, it might point to an array of floats, of a given size, in which case it would be valid to increment 'up to a point.'
2022-11-27 14:11:36 <KipIngram   > Or you could just increment it and so as you will, and you're taking responsibility not to overflow it.
2022-11-27 14:12:08 <KipIngram   > Array types could have max size and now size fields.
2022-11-27 14:12:44 <KipIngram   > Or maybe you just don't worry about that, and let the memory manager grow it for you if you tried ot go outside its existing size.
2022-11-27 14:12:53 <KipIngram   > It would allocate new ropes pages as needed to do that.
2022-11-27 14:36:40 <KipIngram   > Anyway, it seems like it will make all of the necessary information to do "everything right" available, and that's what I will be looking for in such a system.  For it to "just work," and give me the answers I want.  Without me  having to do a bunch of side-bookkeeping to keep things straight.
2022-11-27 14:36:55 <KipIngram   > *Not* what a "ground floor Forth" system should try to do.
2022-11-27 14:37:29 <KipIngram   > I've kind of decided that trying to land halfway in between  just isn't the way to go.
2022-11-27 14:38:47 <KipIngram   > Even the standard conditional words are steps along that spectrum.  They wind up being immediate words that use the stack to pass information around during compilation.  Great - it gives you a capability you otherwise wouldn't have.
2022-11-27 14:39:17 <KipIngram   > But the conditional return words as I now have them are "just words."  They just compile, like any other word, and don't require any "help from the compiler" to do what they need to do.
2022-11-27 14:39:51 <KipIngram   > They are different from most words, because they require a value to be compiled after then.  I do have a bit in the header that calls out such words, so the compiler knows when to put it there.
2022-11-27 14:40:17 <KipIngram   > But no "in the  moment" assistance from data on the stack is needed.
2022-11-27 14:41:09 <KipIngram   > When that post-value is needed, it's always the same thing: it's an offset back from "here" to the start of the most recent definition.
2022-11-27 14:42:03 <KipIngram   > Which is exactly the PFA of LATEST, so it's easy to get it on the fly from the dictionary.
2022-11-27 14:43:01 <KipIngram   > It's exactly the same info tail optimization needs.
2022-11-27 14:44:57 <KipIngram   > Anyway, I started envisioning these conditional looping words, and was immediately struck by how that would require a whole flock of immediate words that compiled run-time parts.  I had no interest in writing all of those.
2022-11-27 14:45:15 <KipIngram   > So I added this bit in the header so it could be done automatically by the compiler.
2022-11-27 14:45:34 <KipIngram   > There's over a hundred of these things - that would just have been a lot of immediate words.
2022-11-27 15:52:32 <olle        > Can I make a math lib like `a b +` where a and b are matrices in Forth?
2022-11-27 15:54:59 <thrig       > how would we know if you can?
2022-11-27 15:55:41 <olle        > Can anyone
2022-11-27 15:55:53 <thrig       > sure, it's just code
2022-11-27 15:55:54 <olle        > Maybe i need to read up on structs
2022-11-27 15:56:09 <olle        > the gforth manual is pretty weak on it
2022-11-27 16:05:14 <jackdaniel  > last 9 values on the stack are 3x3 matrix and voila
2022-11-27 16:05:30 <jackdaniel  > wow, I'll never read this backlog
2022-11-27 16:08:16 <olle        > jackdaniel: sounds fragile
2022-11-27 16:09:00 <jackdaniel  > I thought that you've asked whether it is possible
2022-11-27 16:09:55 <olle        > oh
2022-11-27 16:09:55 <olle        > true
2022-11-27 16:10:59 <olle        > hmmm anyone has a good structs tutorial?
2022-11-27 16:23:56 <veltas      > olle: Yeah of course you can make one
2022-11-27 16:30:25 <veltas      > Lookup +FIELD , FIELD: and CFIELD:
2022-11-27 16:30:34 <olle        > I just did a "see field"
2022-11-27 16:30:45 <olle        > then i wanted to do "see pick" and gforth hangs ><
2022-11-27 16:30:53 <veltas      > Which gforth do you have?
2022-11-27 16:31:13 <olle        > 0.7.3
2022-11-27 16:31:31 <jackdaniel  > use 0.7.6 as advised earlier
2022-11-27 16:31:46 <jackdaniel  > 0.7.9 *
2022-11-27 16:32:10 <veltas      > I've got 0.7.3 on my server and that works
2022-11-27 16:32:14 <olle        > earlier?
2022-11-27 16:32:16 <olle        > lemme check
2022-11-27 16:32:46 <olle        > veltas: Does "see pick" work?
2022-11-27 16:32:57 <veltas      > Yeah
2022-11-27 16:33:17 <veltas      > It's a bit slow though
2022-11-27 16:33:21 <jackdaniel  > earlier today when I've asked which forth should I use to explore
2022-11-27 16:34:25 <olle        > no history here
2022-11-27 16:35:49 <veltas      > olle: Keep gforth installed and download https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz
2022-11-27 16:35:58 <veltas      > And try building that
2022-11-27 16:36:18 <veltas      > I can't build new gforth without old gforth installed
2022-11-27 16:40:20 <olle        > Trying snap first
2022-11-27 16:40:35 <veltas      > olle: https://pastebin.com/raw/eCfF9nGX struct example
2022-11-27 16:40:53 <veltas      > And also I have implemented FIELD: and +FIELD so I guess it's also a struct library example
2022-11-27 16:40:53 <olle        > oh yeah, now "see pick" spits out proper asm
2022-11-27 16:40:59 <olle        > thanks ^^
2022-11-27 16:41:39 <neuro_sys__ > Unrelated, but this guy is doing pretty coold stuff: https://www.youtube.com/watch?v=lGPuhOTb67Y
2022-11-27 16:42:51 <olle        > veltas: hmmm area is not a method there
2022-11-27 16:43:32 <olle        > but get it
2022-11-27 16:45:01 <veltas      > No it's not a method lol
2022-11-27 16:45:14 <veltas      > But you can make a method if you want
2022-11-27 16:45:40 <veltas      > I just chose a SHAPE struct because I've got OOP in my head, not because I was going to do OOP :P
2022-11-27 16:45:50 <olle        > ^^
2022-11-27 16:46:39 <veltas      > There is OOP in forth but why would you want to
2022-11-27 16:46:40 <olle        > veltas: you really need to define field+ and field: ?
2022-11-27 16:46:48 <veltas      > No you don't need to
2022-11-27 16:47:11 <veltas      > But I'm explaining how dirt simple the library is
2022-11-27 16:47:14 <Zarutian_iPad> I recommend object based system over oop(s)
2022-11-27 16:47:47 <veltas      > It's why I don't mind structs in forth, because they're so darn simple
2022-11-27 16:47:49 <thrig       > maybe you do want the whole forest and gorilla in addition to the banana
2022-11-27 16:47:55 <olle        > eeeh see `cell freaks out
2022-11-27 16:48:32 <veltas      > You can even use BEGIN-STRUCTURE and END-STRUCTURE if you hate brevity
2022-11-27 16:48:33 <olle        > but just `cell works
2022-11-27 16:51:25 <veltas      > neuro_sys__: Looks like a good channel
2022-11-27 17:14:00 <neuro_sys__ > https://www.youtube.com/watch?v=2Fixjz3VoSI
2022-11-27 17:14:05 <neuro_sys__ > This brings joy to me :)
2022-11-27 17:17:31 <neuro_sys__ > The development environment itself is portable (just drag and drop the folder, no installation), and you can write assembly for multiple 8-bit machines. I also noticed later he created an environment to write portable assembly for multiple targets (6502, z80, 68K) and various multiple machines (12 different machines or so with different CPUs).
2022-11-27 17:19:06 <olle        > why not just buy one?
2022-11-27 17:20:09 <olle        > https://www.ebay-kleinanzeigen.de/s-anzeige/c-commodore-c64-floppy-1541-joystick-disks-top/2286954597-228-1103
2022-11-27 17:20:12 <olle        > there ya go :)
2022-11-27 17:21:31 <neuro_sys__ > Unfortunately I have amassed several of these machines already, and I can't use them as much as I want to since I don't have enough space to keep them set up.
2022-11-27 17:22:49 <olle        > hehe
2022-11-27 17:34:43 <gordonjcp   > neuro_sys__: which machines?
2022-11-27 17:36:31 <thrig       > at least they're not power hungry PDP-whatevers?
2022-11-27 17:45:03 <neuro_sys__ > gordonjcp: Amstrad CPC 6128, Amiga 500, Commodore 64, ZX Spectrum, Atari 800 XL off the top of my head.
2022-11-27 17:45:26 <neuro_sys__ > I'd have liked to get one of those Russian PDP-11 clones.
2022-11-27 17:47:13 <neuro_sys__ > Like Elektronika bk-0010
2022-11-27 17:51:36 <olle        > You run Collapse OS on all of them? :)
2022-11-27 18:07:21 <KipIngram   > Those were great technology days.  :-)
2022-11-27 18:07:43 <thrig       > ... and we liked having to erase the copper contacts with a #2 pencil
2022-11-27 18:07:49 <KipIngram   > We were "on our way up the curve," so to speak.  You couldn't turn around without something new and better popping up.
2022-11-27 18:08:06 <KipIngram   > :-)
2022-11-27 18:08:20 <KipIngram   > Yeah, or chasing down a cold solder joing... somewhere.
2022-11-27 18:08:26 <KipIngram   > joint
2022-11-27 18:09:09 <KipIngram   > It could be pretty satisfying, though, the times you could just think carefully about what wasn't working and figure out where the problem almost had to be - and then found it there.
2022-11-27 18:09:46 <thrig       > helped when the stereo system came with a circuit diagram
2022-11-27 19:08:13 <gordonjcp   > ah, neuro_sys left
2022-11-27 19:08:22 <gordonjcp   > if they pop back again, tell them they need a Jupiter Ace