2024-11-27 00:02:20 anyway, turning in for the night :) - thanks again for the help :) 2024-11-27 00:32:23 there are a number of examples of infix to postfix in Forth 2024-11-27 00:32:38 they're generally pretty short 2024-11-27 00:47:15 Chuck outlines an approach for infix to postfix in his "Programming a Problem-Oriented Language" book. 2024-11-27 00:48:08 It uses an "operation stack" data structure. Since you can come to an operation before you have all the operands, you have to remember it somewhere. Tags on the operators carry precedence info and tell you when to pop and evaluate. 2024-11-27 00:48:48 That was early on when Chuck still seemed to feel he had to "address things" that people would complain about. He... got over that later. 2024-11-27 00:50:53 Interesting book. Forth wasn't nearly fully mature yet; it's interesting to see those earlier forms of things. 2024-11-27 00:50:57 Colon defs weren't even compiled yet. They were more like macros that got saved and text-expanded on demand. So basically everything ran and interpreter speed. 2024-11-27 00:51:04 s/and/at/ 2024-11-27 01:44:56 yeah. which kind of informs my view that for him Forth was, more than anything else, a high-level scripting language for assembly 2024-11-27 01:55:08 I think that was the initial idea, yes. 2024-11-27 01:58:35 It would be interesting to know where Chuck's first exposure to RPN came. My kneejerk thought would have been "HP calculators," but HP didn't introduce their first one until 1972, which is too late. Of course RPN had been around since the 1920's, and had shown up in products from other companies. 2024-11-27 02:04:23 I think *reverse* Polish notation first showed up in the 50s in a variety of different places, but the first HP calculator to use it was the HP 9100A, which came out in 01968, following the Olivetti Programma 101, which came out in 01965 and also used RPN 2024-11-27 02:05:58 the Burroughs B5000 was probably the most famous early stack machine; its design started in 01961 and I think it was announced in 01962 or so 2024-11-27 02:06:18 https://en.wikipedia.org/wiki/Jan_%C5%81ukasiewicz#Work 2024-11-27 02:06:45 yeah, that was the not-reverse Polish notation 2024-11-27 02:07:54 but there were a few different independent inventions in the 50s of the reversed form used by the B5000, Forth, HP calculators, etc. 2024-11-27 02:16:33 also it may be notable that Wirth and Weber published a tech report on a language called "Euler" in 01965, describing its semantics in terms of a stack machine: http://i.stanford.edu/pub/cstr/reports/cs/tr/65/20/CS-TR-65-20.pdf 2024-11-27 02:16:57 see for example the definition of < on p. 71 (p.83/130) 2024-11-27 02:19:05 Forth's @ is value in Euler, I think 2024-11-27 03:08:25 hi 2024-11-27 03:10:56 bonne nuit 2024-11-27 03:18:03 I wonder WHY forth use Reverse polish notation instead of polish notation 2024-11-27 03:21:44 Because it's easier for computers 2024-11-27 03:21:57 And actually, with some practice, you begin to realize it's easier for humans too! 2024-11-27 03:49:58 right. in RPN the operations are written from left to right in the same order they take place in; (2+3)*4 is 2 3 + 4 * because the multiplication happens after the addition. in Łukasiewicz's notation it's * + 2 3 4, which is perfectly unambiguous but requires evaluation from right to left 2024-11-27 03:53:17 I mean, you can certainly look at each token from left to right and decide what to do, performing the addition when you see the 3 and the multiplication when you see the 4, but it's more complex to do it that way 2024-11-27 04:02:42 From a processing stand point I think it also makes more sense too. You need data before you do anything. 2024-11-27 04:03:09 "Add" - add what? There is no data to add. 1 3 add ? Very simple. 1 and 3 are available to add. 2024-11-27 04:03:38 I started to even try algebra this way 2024-11-27 04:03:41 It's actually 100% better 2024-11-27 04:24:52 well, as you probably know from LR parsing, you can define a fairly simple one-stack machine that handles * + 2 3 4 or even ( 2 + 3 ) * 4 2024-11-27 04:25:25 it just needs to put things on the stack that aren't unadorned numbers 2024-11-27 04:26:56 I haven't tried RPN algebraic manipulation myself but I feel like it will be more error-prone than pop infix. I'm not sure how much of that is just familiarity 2024-11-27 04:27:05 maybe for you it isn't! 2024-11-27 04:59:32 It's totally unfamiliarity that will make it difficult 2024-11-27 05:00:01 Yes you can define a 1 stack machine that handles prefix more easily, but prefix fundamentally takes more memory 2024-11-27 05:00:26 RPNs advantage is not needing to denote groupings 2024-11-27 05:00:38 You also consume data eagerly 2024-11-27 05:00:43 * + 2 3 4 is not eager 2024-11-27 05:00:54 * cant operate at all 2024-11-27 05:01:14 2 3 + 4 * in comparison 2024-11-27 05:01:26 immediate computation, optimal memory usage 2024-11-27 05:02:06 i think there isnt anything to gain necessarily for a human 2024-11-27 05:02:21 but I do believe humans would find this _easier_ if it were the defacto 2024-11-27 05:02:45 we spend 10+ years in our early years though learning infix. that's hard to break. impossible for some mostly. 2024-11-27 05:09:07 Guess I'll try this again tomorrow. Says connection refused now, despite the socket file being there 2024-11-27 05:09:15 https://gist.github.com/xcombelle/1ee28a3de056b431723cef78849e7509 2024-11-27 05:09:16 possibly it's true that prefix fundamentally takes mor memory 2024-11-27 05:09:22 *more 2024-11-27 05:09:31 (whoops wrong channel) 2024-11-27 05:10:54 a 30 lines of python which eval --> print mult int 2 add int 3 int 5 2024-11-27 05:10:54 yeah, using the Python stack (and thus the C stack) 2024-11-27 05:11:03 basically recursive descent parsing 2024-11-27 05:11:54 I think it's arguable whether that's strictly a one-stack machine! 2024-11-27 05:13:36 it's a bit like tcl actually 2024-11-27 05:18:44 yeah. or REBOL/Red 2024-11-27 05:28:16 sadly rebol/red depend on rebol2 to make their executable 2024-11-27 07:36:48 I think the most obvious reason for thr decline of Forth is the blanket statement that it is an interpreter. The fact is that modern Forths, like Mecrisp is very fast. Forth is also very close to wires in embedded systems and gets rid of the tedious compile, download, run cycle. But I am talking to the conveted. For anyone working on modern 2024-11-27 07:36:49 embedded systems, MecrispCUBE deserves a look. 2024-11-27 07:37:05 *are 2024-11-27 08:23:03 xentrac: haven't found one online myself - you got a link? either way, rpn is always my preference for doing any kind of maths, and my main reason for introducing an abstraction is purely because in my case, the maths is all floating point - i don't want to lumber the user with the exponent issue, nor the f+/f-/fsin etc etc 2024-11-27 08:26:53 also i'd ultimately x followed by superscript 2 for instead of x ** 2 and vectors should be a vertical column rather than a horizontal one and so on 2024-11-27 08:29:01 it would feel much more natural to that kind of presentation thing in, well, something other than forth? 2024-11-27 08:34:46 Well, in Forth you can allways do x **2 2024-11-27 08:35:55 :) - 2 was an example - 2 ** 2.5 is also good :) 2024-11-27 08:38:11 normal mathematical notation does not introduce special operators just because move from natural to real to complex - it's fine to translate an input which meets the requiremnents of forth, but hardly reasonable to impose that on a user 2024-11-27 08:40:07 (sorry for typos - don't seem to be completely awake at the moment :)) 2024-11-27 08:44:08 s/move/we move/ s/input which meets/input to meet/ 2024-11-27 13:14:19 skvery: isn't Mecrisp proprietary? 2024-11-27 13:20:18 lilo_booter: I haven't tested https://arduino-forth.com/article/FORTH_exemples_convertInfixToPostfix but it claims to work in GForth. Brad Rodriguez also used infix parsing as his example in https://www.bradrodriguez.com/papers/bnfparse.htm which is written in I think Forth-79 2024-11-27 13:23:29 xentrac: thanks - will look into them :) 2024-11-27 13:26:58 and there's another one by Michael Stolowitz in Forth Dimensions volume IV no. 6 using the shunting-yard algorithm: https://www.forth.org/fd/FD-V04N6.pdf#page=14 2024-11-27 13:27:41 which uses create does> instead of Rodriguez's Forth-79-like despite being from 01982 rather than 01988 2024-11-27 13:28:21 "Forth Scientific Library" https://vfxforth.com/flag/fsl/index.html 2024-11-27 13:35:11 someone pointed out the other night that Chuck Moore's "Problem-Oriented Language" book describing an early Forth also describes the shunting-yard algorithm for infix parsing: https://www.forth.org/POL.pdf#page=121 2024-11-27 13:35:25 from 01970 2024-11-27 13:40:24 and Andrew Haley gave a talk on "An infix syntax for Forth" for EuroFORTH '08 whose slides are at http://www.complang.tuwien.ac.at/anton/euroforth/ef08/papers/haley.pdf and seem to include the full source on one slide 2024-11-27 13:42:34 it takes a different approach