6 ms·

Show HN: Easy Forth

122 points by skilldrick 11y ago

zatkin 11y ago
Everything is great, simple, and easy to understand, and then I get to that Snake example and the code is nearly unreadable.
- abecedarius 11y ago
  The Snake code is more complex than it needs to be -- example: defining directions as constants from 1 to 4 and then using IF on the direction, instead of defining directions as offsets in the coordinates. But simpler code would not be that much simpler -- Forth just takes getting used to, and I guess the step up to a whole game was too steep. Add some smaller exercises first? Like Sokoban? (Generally the main thing that'd make Forth more readable is local variables in place of stack manipulations.)
  - to3m 11y ago
    If you really insist on having an enum for your directions, what you could do is something like this: (assuming 2s complement and TRUE being ~0) : DIREQ DIRECTION @ = ; : DELTA DIREQ SWAP DIREQ NEGATE + ; : MOVE-SNAKE-HEAD LEFT RIGHT DELTA SNAKE-X-HEAD +! UP DOWN DELTA SNAKE-Y-HEAD +! ; It's an open question whether this approach is any better but I think it looks a bit more Forthlike, insofar as I have any grasp of what that is. I think having offsets would make more sense - e.g., suppose your playfield is 80 units wide, then you'd have left and right as -1 and +1, and up and down as -80 and +80 (which I assume is what you mean).
  - voltagex_ 11y ago
    Raise an issue about it? https://github.com/skilldrick/easyforth/issues https://github.com/skilldrick/easyforth/issues
richdougherty 11y ago
Nice! If you like Forth, there's information about similar languages over at http://concatenative.org/ http://concatenative.org/.
- deleted 11y ago
  [deleted]
berntb 11y ago
Fun environment. A couple of weeks ago I installed 8th to learn a Forth as a hobby. (It promised iOS integration, so it might even be useful. I'm not there yet. :-) )
vive-la-liberte 11y ago
I often use dc(1) so my first instinct was to type "1 2 3 +" into the input without intermediate linebreaks. I was delighted to see that this was correctly understood to mean what I wanted to express instead of it doing something silly like taking just the first int of my string or trying to parse the string as a whole straight to int. These are the sort of things which encourage readers to read on :) Edit: Unfortunatelly, when I try to scroll and read the rest, the input field steals focus rendering me unable to continue. Firefox on Android.
- brudgers 11y ago
  Not directly a solution, but there is GNU Forth for Android. https://play.google.com/store/apps/details?id=gnu.gforth&hl=e https://play.google.com/store/apps/details?id=gnu.gforth&hl=...
peter303 11y ago
Forth programs are very compact. And so are Forth intepreters. Great for 1970s PCs with memories as small as 8K. But postfix programs are hard to understand. An hour later and you've forgotten what you have written.
- klibertp 11y ago
  Also great for myriads of devices with constrained memory and computing power we use every day in 2015. > But postfix programs are hard to understand No. Badly written programs are hard to understand. That's true for every language. Also, programs written in a language you don't know are hard to understand. That's obvious, right? Postfix, prefix or infix notations have little to do with this. There are natural languages written from right to left, and also ones written from right to left and vertically at that. Are they "hard to understand" for people who use them? What do you think?
  - deleted 11y ago
    [deleted]
  - TazeTSchnitzel 11y ago
    The direction a language is written in has no bearing on how easy it is to understand. Postfix is a different matter altogether.
    - klibertp 11y ago
      Wait, why? Could you elaborate? How is: + 1 2 fundamentally different from: 1 2 + ? You just look for the operator on the other side of arguments. I know both prefix, postfix and "crazy infix" (J, some APL) languages and I really don't see a qualitative difference. Of course, after you overcome the initial hurdle and get used to the notation. EDIT: ok, J/K/APL are a special case and I shouldn't mention them.
      - kazinator 11y ago
        It's not the direction, it's the lack of delimiting. ((1 2 +) (3 4 +) *) is fundamentally different from 1 2 3 4 + + * Each word has a clear arity, and the arguments are delimited. We can follow the evaluation of the parenthesized expression in multiple orders and they come up with the same answer.
danbolt 11y ago
This is an enjoyable read! I've been coming across mentions of Forth much more often lately, so it feels satisfying being able to get a sense of it. One thing that caught my attention is that Forth's boolean value for "false" is 0, and for "true" is -1. This makes sense if you look at their binary values, being 00000000 and 11111111, respectively. Does anyone know if there was an underlying design decision for this? Fast hardware checking? Bit masking tricks?
- abecedarius 11y ago
  Bit masking tricks (though Leo Brodie objected to calling that kind of code a 'trick'). Kind of amusing history: in FORTH-79 tests returned 1 for true, then FORTH-83 changed it, and also changed NOT to mean bitwise complement because you could use 0= for logical complement. Confusion! In the next standard NOT was left undefined, or rather they changed the name to INVERT.
- TazeTSchnitzel 11y ago
  If you define it like that, you don't need separate boolean and bitwise AND and OR. 11111111 & 00000000 = 00000000, 11111111 | 00000000 = 11111111, ~11111111 = 00000000 etc. QBASIC (and possibly other Microsoft BASIC dialects?) did the same thing. There's no &&, || or ! in QBASIC. If you define "true" as just 00000001 then it works for & and |, but not for ~.
tonyonodi 11y ago
This looks amazing! Thank you. I've been meaning to learn Forth since forever now.
david-given 11y ago
A couple of months ago I wrote a Forth interpreter, because I'd always wanted to. I haven't really used it in anger, but passes the basic ANS Forth tests, so it should be reasonably complete. (It's here: https://github.com/EtchedPixels/FUZIX/blob/master/Applications/util/fforth.c https://github.com/EtchedPixels/FUZIX/blob/master/Applicatio... It's a single, portable C file which is also an executable shell script containing an awk script! It compiles to about 8kB of code on a microcontroller.) From the experience I learnt two main things about Forth: (a) the realisation of how Forth works, and the way in which the language bootstraps itself out of nothingness, and the way in which it takes about two basic principles and then builds an entire language out of them, is truly mind expanding. The process was full of 'aaah!' moments when it all came together and I realised just how elegant it was. (b) actually engineering a Forth interpreter, and dealing with the ANS spec, was an exercise in frustration. Those elegant principles are compromised at every stage of the process. The spec defines things which no sane person would define. I'd implement a word, and it'd be clean and work, and then the ANS tests would fail and I would realise that the specification dictates a particular half-arsed implementation which makes no sense whatsoever. The process was full of 'uuugh!' moments when I saw a thing in the spec and realised how much more complicated it would make my life. Examples follow: - double words are pushed onto the stack in high word / low word order. Regardless of whether your architecture is big or little endian. Good luck with using 64 bit load/store instructions! - DO...LOOP is defined to use the return stack for temporary storage. Valid Forth programs can't call EXIT from inside a DO...LOOP structure. If you try, your program does a hyperspace jump and crashes. - BEGIN...REPEAT is defined not to use the return stack for temporary storage. Valid Forth programs are allowed to call EXIT from inside a BEGIN...REPEAT structure. - DO...LOOP has different termination characteristics depending on whether you're counting up or down. - Mismatched control flow structures are not just not detected, but they are actually, in certain combinations, defined to work. The spec actually defines what some of them do --- IF, THEN, BEGIN, WHILE, REPEAT, if I recall correctly --- and lets you mix and match them. Good luck if you want to use different, more efficient implementations. - The memory model assumes that Forth is the sole owner of the memory. It starts at the bottom and works up. When compiling a word, you have to decide what address it's being written to before you know how long it's going to be. Want to share the heap with something else? Good luck with that. - Division. How overcomplicated can it be? Answer: extremely. - Rearranging values on the stack gets old very, very, very quickly. - Forth isn't typed! Except where it is, and it doesn't check them, and if you get them wrong my the gods have mercy on your soul, because the interpreter surely won't. I would still say that anybody with any interest in programming should learn at least the basics of Forth, and should write at least the core of a Forth interpreter. (It won't take long, and you'll learn a hell of a lot.) But I'd be really hesitant about recommending it for real programming use, other than for the special niches where it excels, such as embedded systems. Most of the problem is that it's overspecified; it would be so much simpler, faster, and easier to understand if the spec had more undefined behaviour in it. I now understand why so many people just ignore it and write their own dialect. Strong type checking would really help, too.

122 points by skilldrick 11y ago

Everything is great, simple, and easy to understand, and then I get to that Snake example and the code is nearly unreadable.

abecedarius 11y ago
The Snake code is more complex than it needs to be -- example: defining directions as constants from 1 to 4 and then using IF on the direction, instead of defining directions as offsets in the coordinates. But simpler code would not be that much simpler -- Forth just takes getting used to, and I guess the step up to a whole game was too steep. Add some smaller exercises first? Like Sokoban? (Generally the main thing that'd make Forth more readable is local variables in place of stack manipulations.)
- to3m 11y ago
  If you really insist on having an enum for your directions, what you could do is something like this: (assuming 2s complement and TRUE being ~0) : DIREQ DIRECTION @ = ; : DELTA DIREQ SWAP DIREQ NEGATE + ; : MOVE-SNAKE-HEAD LEFT RIGHT DELTA SNAKE-X-HEAD +! UP DOWN DELTA SNAKE-Y-HEAD +! ; It's an open question whether this approach is any better but I think it looks a bit more Forthlike, insofar as I have any grasp of what that is. I think having offsets would make more sense - e.g., suppose your playfield is 80 units wide, then you'd have left and right as -1 and +1, and up and down as -80 and +80 (which I assume is what you mean).
- voltagex_ 11y ago
  Raise an issue about it? https://github.com/skilldrick/easyforth/issues https://github.com/skilldrick/easyforth/issues

richdougherty 11y ago

Nice! If you like Forth, there's information about similar languages over at http://concatenative.org/ http://concatenative.org/.

deleted 11y ago
[deleted]

berntb 11y ago

Fun environment. A couple of weeks ago I installed 8th to learn a Forth as a hobby. (It promised iOS integration, so it might even be useful. I'm not there yet. :-) )

vive-la-liberte 11y ago

I often use dc(1) so my first instinct was to type "1 2 3 +" into the input without intermediate linebreaks. I was delighted to see that this was correctly understood to mean what I wanted to express instead of it doing something silly like taking just the first int of my string or trying to parse the string as a whole straight to int. These are the sort of things which encourage readers to read on :) Edit: Unfortunatelly, when I try to scroll and read the rest, the input field steals focus rendering me unable to continue. Firefox on Android.

brudgers 11y ago
Not directly a solution, but there is GNU Forth for Android. https://play.google.com/store/apps/details?id=gnu.gforth&hl=e https://play.google.com/store/apps/details?id=gnu.gforth&hl=...

peter303 11y ago

Forth programs are very compact. And so are Forth intepreters. Great for 1970s PCs with memories as small as 8K. But postfix programs are hard to understand. An hour later and you've forgotten what you have written.

klibertp 11y ago
Also great for myriads of devices with constrained memory and computing power we use every day in 2015. > But postfix programs are hard to understand No. Badly written programs are hard to understand. That's true for every language. Also, programs written in a language you don't know are hard to understand. That's obvious, right? Postfix, prefix or infix notations have little to do with this. There are natural languages written from right to left, and also ones written from right to left and vertically at that. Are they "hard to understand" for people who use them? What do you think?
- deleted 11y ago
  [deleted]
- TazeTSchnitzel 11y ago
  The direction a language is written in has no bearing on how easy it is to understand. Postfix is a different matter altogether.
  - klibertp 11y ago
    Wait, why? Could you elaborate? How is: + 1 2 fundamentally different from: 1 2 + ? You just look for the operator on the other side of arguments. I know both prefix, postfix and "crazy infix" (J, some APL) languages and I really don't see a qualitative difference. Of course, after you overcome the initial hurdle and get used to the notation. EDIT: ok, J/K/APL are a special case and I shouldn't mention them.
    - kazinator 11y ago
      It's not the direction, it's the lack of delimiting. ((1 2 +) (3 4 +) *) is fundamentally different from 1 2 3 4 + + * Each word has a clear arity, and the arguments are delimited. We can follow the evaluation of the parenthesized expression in multiple orders and they come up with the same answer.

danbolt 11y ago

This is an enjoyable read! I've been coming across mentions of Forth much more often lately, so it feels satisfying being able to get a sense of it. One thing that caught my attention is that Forth's boolean value for "false" is 0, and for "true" is -1. This makes sense if you look at their binary values, being 00000000 and 11111111, respectively. Does anyone know if there was an underlying design decision for this? Fast hardware checking? Bit masking tricks?

abecedarius 11y ago
Bit masking tricks (though Leo Brodie objected to calling that kind of code a 'trick'). Kind of amusing history: in FORTH-79 tests returned 1 for true, then FORTH-83 changed it, and also changed NOT to mean bitwise complement because you could use 0= for logical complement. Confusion! In the next standard NOT was left undefined, or rather they changed the name to INVERT.
TazeTSchnitzel 11y ago
If you define it like that, you don't need separate boolean and bitwise AND and OR. 11111111 & 00000000 = 00000000, 11111111 | 00000000 = 11111111, ~11111111 = 00000000 etc. QBASIC (and possibly other Microsoft BASIC dialects?) did the same thing. There's no &&, || or ! in QBASIC. If you define "true" as just 00000001 then it works for & and |, but not for ~.

tonyonodi 11y ago

This looks amazing! Thank you. I've been meaning to learn Forth since forever now.

david-given 11y ago

A couple of months ago I wrote a Forth interpreter, because I'd always wanted to. I haven't really used it in anger, but passes the basic ANS Forth tests, so it should be reasonably complete. (It's here: https://github.com/EtchedPixels/FUZIX/blob/master/Applications/util/fforth.c https://github.com/EtchedPixels/FUZIX/blob/master/Applicatio... It's a single, portable C file which is also an executable shell script containing an awk script! It compiles to about 8kB of code on a microcontroller.) From the experience I learnt two main things about Forth: (a) the realisation of how Forth works, and the way in which the language bootstraps itself out of nothingness, and the way in which it takes about two basic principles and then builds an entire language out of them, is truly mind expanding. The process was full of 'aaah!' moments when it all came together and I realised just how elegant it was. (b) actually engineering a Forth interpreter, and dealing with the ANS spec, was an exercise in frustration. Those elegant principles are compromised at every stage of the process. The spec defines things which no sane person would define. I'd implement a word, and it'd be clean and work, and then the ANS tests would fail and I would realise that the specification dictates a particular half-arsed implementation which makes no sense whatsoever. The process was full of 'uuugh!' moments when I saw a thing in the spec and realised how much more complicated it would make my life. Examples follow: - double words are pushed onto the stack in high word / low word order. Regardless of whether your architecture is big or little endian. Good luck with using 64 bit load/store instructions! - DO...LOOP is defined to use the return stack for temporary storage. Valid Forth programs can't call EXIT from inside a DO...LOOP structure. If you try, your program does a hyperspace jump and crashes. - BEGIN...REPEAT is defined not to use the return stack for temporary storage. Valid Forth programs are allowed to call EXIT from inside a BEGIN...REPEAT structure. - DO...LOOP has different termination characteristics depending on whether you're counting up or down. - Mismatched control flow structures are not just not detected, but they are actually, in certain combinations, defined to work. The spec actually defines what some of them do --- IF, THEN, BEGIN, WHILE, REPEAT, if I recall correctly --- and lets you mix and match them. Good luck if you want to use different, more efficient implementations. - The memory model assumes that Forth is the sole owner of the memory. It starts at the bottom and works up. When compiling a word, you have to decide what address it's being written to before you know how long it's going to be. Want to share the heap with something else? Good luck with that. - Division. How overcomplicated can it be? Answer: extremely. - Rearranging values on the stack gets old very, very, very quickly. - Forth isn't typed! Except where it is, and it doesn't check them, and if you get them wrong my the gods have mercy on your soul, because the interpreter surely won't. I would still say that anybody with any interest in programming should learn at least the basics of Forth, and should write at least the core of a Forth interpreter. (It won't take long, and you'll learn a hell of a lot.) But I'd be really hesitant about recommending it for real programming use, other than for the special niches where it excels, such as embedded systems. Most of the problem is that it's overspecified; it would be so much simpler, faster, and easier to understand if the spec had more undefined behaviour in it. I now understand why so many people just ignore it and write their own dialect. Strong type checking would really help, too.