4 ms·

Leaving out numeric literals is an interesting choice to simplify your Forth kernel. Not many languages have sufficiently flexible naming rules to permit someth

Leaving out numeric literals is an interesting choice to simplify your Forth kernel. Not many languages have sufficiently flexible naming rules to permit something like ": 3 1 2 + ;" Stylistically, one of the main suggestions I took to heart early in my career with Forth was to outright ignore "rot" and "-rot"; they make the stack tricky to follow. I see that helloworld.f defines "rot", but it's only used in one place.

samatman 6y ago
Related advice would be to annotate every stack effect with a comment, no exceptions. Back when I was into Forth, I had this wild notion of adding a stack checker, defining two additional comment words which would be aware of the stack effect of all core words, and require a stack effect to be defined for every new piece of vocabulary. Never did anything with it, don't write Forth anymore, doubt I will again. I still think it's a good idea though, so I like to put it out there.
- TapamN 6y ago
  That's actually been done. It's called StrongForth. http://www.arestlessmind.org/2009/02/03/intro.html http://www.arestlessmind.org/2009/02/03/intro.html
  - MaxBarraclough 6y ago
    You beat me to it. See also this other page on StrongForth: https://www.stephan-becher.de/strongforth/ https://www.stephan-becher.de/strongforth/ See also the Kitten programming language, which does something similar: https://kittenlang.org/ https://kittenlang.org/
- dfischer 6y ago
  Have you seen Factor? https://factorcode.org/ https://factorcode.org/
- cblum 6y ago
  Yep, annotating the examples with stack effects is in my plans :)
cblum 6y ago
Oh, interesting. I feel like I've gotten used to reasoning with rot and -rot. Didn't know there was advice out there not to use it.
- loa_in_ 6y ago
  It's not any more or less intuitive to me than nip and over. Where there's three or more items to be manipulated there's always at least ambiguity which way rot is supposed to rotate according to codebase author. With more than three items it's easy to see what can be done but no unambiguous and meaningful names. The only consistent stack word names that work 4 items deep are 2dup and 2drop.

samatman 6y ago

Related advice would be to annotate every stack effect with a comment, no exceptions. Back when I was into Forth, I had this wild notion of adding a stack checker, defining two additional comment words which would be aware of the stack effect of all core words, and require a stack effect to be defined for every new piece of vocabulary. Never did anything with it, don't write Forth anymore, doubt I will again. I still think it's a good idea though, so I like to put it out there.

TapamN 6y ago
That's actually been done. It's called StrongForth. http://www.arestlessmind.org/2009/02/03/intro.html http://www.arestlessmind.org/2009/02/03/intro.html
- MaxBarraclough 6y ago
  You beat me to it. See also this other page on StrongForth: https://www.stephan-becher.de/strongforth/ https://www.stephan-becher.de/strongforth/ See also the Kitten programming language, which does something similar: https://kittenlang.org/ https://kittenlang.org/
dfischer 6y ago
Have you seen Factor? https://factorcode.org/ https://factorcode.org/
cblum 6y ago
Yep, annotating the examples with stack effects is in my plans :)

cblum 6y ago

Oh, interesting. I feel like I've gotten used to reasoning with rot and -rot. Didn't know there was advice out there not to use it.

loa_in_ 6y ago
It's not any more or less intuitive to me than nip and over. Where there's three or more items to be manipulated there's always at least ambiguity which way rot is supposed to rotate according to codebase author. With more than three items it's easy to see what can be done but no unambiguous and meaningful names. The only consistent stack word names that work 4 items deep are 2dup and 2drop.