Show HN: Easy Forth(skilldrick.github.io) |
Show HN: Easy Forth(skilldrick.github.io) |
If you like Forth, there's information about similar languages over at http://concatenative.org/.
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.
https://play.google.com/store/apps/details?id=gnu.gforth&hl=...
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?
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 ~.
Postifix with no syntactic delimitation is hard to understand.
The problem with Forth is that although we undersatnd what each word does in isolation, when we look at a word in the middle of the program, we do not have an instant idea about what material to the left of the word produces its arguments and how, and what material to the right consumes its result. We have to go back and simulate the stack machine in our mind to work this out.
What does this do? w1 w2 w3 w4?
We have to know what w1 through w4 do to understand how their data flows are connected together! That's just wrong. In any sane language, we don't have to know what w4 exactly does in order to understand that, for instance, takes two inputs produced by w1 through w3.
The above words could be totally independent from each other, and produce four operands on the stack. Or it could be that they thread a value through them: each one transforms the top word on the stack.
The expressions in a nice, nested, functional notation give us the functional tree at a glance. We can achieve this while keeping the notation postfix, by adding parentheses:
(w1 w2 w3)w4
((w1)w2 w3)w4
Moreover, now we can reason about different evaluation orders, as long as we know there are no side effects. I can think about w3 and then w2 and w1, or vice versa.
Moreover, if w4 is declared as requiring exactly one argument, the error is now statically obvious.
> 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?
(Generally the main thing that'd make Forth more readable is local variables in place of stack manipulations.)
: DIREQ DIRECTION @ = ;
: DELTA DIREQ SWAP DIREQ NEGATE + ;
: MOVE-SNAKE-HEAD
LEFT RIGHT DELTA SNAKE-X-HEAD +!
UP DOWN DELTA SNAKE-Y-HEAD +! ;
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).
(It's here: 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.
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. :-) )
+ 1 2
1 2 +
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.
Can you parse the following easily?
c_z x * s_z y * s_y * c_y z * + c_x * c_z y * s_z x * - s_x * - d_z =
Compare that to the infix form:
d_z = c_x * (c_y * z + s_y * (s_z * y + c_z * x)) - s_x * (c_z * y - s_z * x)
With infix, the operator sits between its operands, so you can easily see what expression makes up the first operand, and which makes up the second: you just look to its left and its right. Postfix, however, requires you to read the entire expression, because the operator doesn't show which operands it has, they're just whatever the last two were, and those last two might themselves be complex expressions. This gets worse the longer the total length of the expression.
Postfix also suffers from not making it clear how many operands a given operator takes. With infix this is always clear.
I like postfix languages for their simplicity, but I refuse to pretend they are as easy to read as infix languages.
(example was taken from https://en.wikipedia.org/wiki/3D_projection#Perspective_proj...)
Anyway, let's try doing something with your postfix example (I hope it displays alright; also, I think you made a mistake in your translation to postfix, but I left it as it is):
c_z x *
s_z y *
s_y *
c_y z *
+
c_x *
c_z y *
s_z x *
-
s_x *
-
d_z =
Of course, it's only more readable for me, with my particular background knowledge and habits; I'm not saying this is or should be the same for anyone else. But, if there are people who see one form as more readable and people who see the other form as more readable, then I think that's a solid argument in favor of both forms not being drastically, qualitatively different.
The problems you point to are definitely real; it's true "the operator doesn't show which operands it has" by default (for example) and you need to go out of your way to show it. But infix notation has it's problems too, and you need to work around them as well. Like operator precedence, which is frankly a terrible idea.
> Postfix also suffers from not making it clear how many operands a given operator takes. With infix, this is always clear.
No, not always. J has words which take one argument on the left and, for example, two on the right. Or three. Or a variable number of arguments on the left (granted, they are `tied` with ` word, but still) and nothing on the right... And Ken Iverson says it's very readable! (To him, at least).
To summarize: I'm still not convinced that there is a major and unfixable difference in readability between the notations, and I still think you can make all 3 notations as readable as any other.
((1 2 +) (3 4 +) *)
1 2 3 4 + + *
And in Forth case, you can very easily define your own delimiters:
: [ ;
: ] ;
[ [ 1 2 + ] [ 3 4 + ] * ] .
21 ok
I mean, there is no rule saying that postfix notation cannot provide grouping constructs. I still fail to see a fundamental difference here :)
BTW, it's not going as fast as I'd like, but I managed to parse TXR man page and use it for displaying docs along auto-completion: https://github.com/piotrklibert/txr-mode/blob/master/screen....
I think I'll be able to find some time this weekend (or next weekend) to clean up the code and make it usable for others as well :)
If I already know that the code is correct and properly indented, then it helps the readability.
> And in Forth case, you can very easily define your own delimiters:
Those delimiters do nothing but occupy interpreter cycles. Hopefully they get recognized as noops and optimized away by a Forth compiler.
The machine will accept garbage like:
] 3 2 + [ 4 /
A sloppily written code is hard to understand correctly in every language (to different degrees, of course). You can easily mistake
if (...)
do1();
do2();
if (...) {
do1();
do2();
}
> Those delimiters do nothing but occupy interpreter cycles. Hopefully they get recognized as noops and optimized away by a Forth compiler.
I'd expect so.
> The machine will accept garbage like: > ] 3 2 + [ 4 /
Yup. And by the way, this garbage is actually nearly correct J code. One possible fix would look like:
] 3 2 + [ 4 (+ /) [ 4
> Forth should have these markers built-in so they don't have to be defined as words, and it should check their pairing and nesting.
That's unnecessary in Forth, I'm sure you can implement a "real" - with a semantic meaning - grouping in Forth yourself. Comments in Forth are enclosed in parens, and the parens are normal Forth words, defined in Forth. I mean, it's already a grouping syntax with a DROP semantics; you can probably define grouping syntax with other semantics as well.
Also, in Forth there are only words, and the syntax is that simple, but that isn't a property of all postfix languages. We're talking about postfix as a notation in general, not about it's particular brand practiced by Forth. This is why I keep mentioning J, again and again: it's an infix language. I could bash infix notation forever had I used J as an example! It's the same with postfix notation and Forth.