8 ms·

>High-level, what makes Forth interesting? What are it’s major strengths and weaknesses? Strengths: Lisp-level metaprogramming facilities while also being extr

>High-level, what makes Forth interesting? What are it’s major strengths and weaknesses? Strengths: Lisp-level metaprogramming facilities while also being extremely fast and close to the metal. Weakness: the Perl problem (write-only) but worse.

RodgerTheGreat 7y ago
It's also important to observe that Forth's approach to metaprogramming is very powerful, but completely different from Lisp's approach. It's not just another retread of the same ideas. CREATE...DOES>, immediate words, parsing words, fancy tricks with the rstack and other fun Forth stuff has at best very loose analogs in Lisp macros.
- DennisP 7y ago
  Where could I get a good tutorial on Forth metaprogramming?
  - RodgerTheGreat 7y ago
    I think the late J.V. Noble's "A Beginner's Guide to Forth" does a good job introducing the language and touching on some metaprogramming features. Near the end he demonstrates a library which extends the language to support infix math expressions (a "FORTRAN") to make scientific computing more convenient. https://www.taygeta.com/fsl/docs/551.jvn.fall01/primer.htm#create https://www.taygeta.com/fsl/docs/551.jvn.fall01/primer.htm#c...
wrycoder 7y ago
Write-only, because only the functions (‘WORDS’) are named - no parameter names. There are also no local variables in standard Forth, you have to push (and pop!) them from the separate return stack. Accessing parameters is done by manipulating the stack, which makes the code opaque after a year or so. Named constants and variables are all global. So, it is very difficult for a team to use, since most of the legibility of software comes from insightfully selected names. Two thirds of those names, at least, are missing in Forth. Like assembler, Forth is untyped. These failings could be at least partly forgiven if Forth was fast. But it isn’t, because most words are short and all the stack manipulations are done with subroutine calls. It’s possible to write an inlining, optimizing compiler, but then the simple layout of code in memory is lost, and quick introspection using a memory dump becomes nearly impossible. But, it is a neat tool to bootstrap a working system quickly on new, embedded hardware with limited resources. Definitely a black belt tool for lightweight systems written by a single person. Hard on maintenance programmers. See Jonesforth for a tutorial example. I wrote a Forth a few decades ago. The insight gained reminds me of Nand2tetris, but the latter is far more mainstream.
- szemet 7y ago
  all the stack manipulations are done with subroutine calls This can have an advantage: one can stuff much more code (and functionality) in a very memory limited system (e.g. smart cards), especially with WORDS compression: "Huffman threaded code is one of the most compact representations known for a computer program" https://en.wikipedia.org/wiki/Threaded_code#Huffman_threading https://en.wikipedia.org/wiki/Threaded_code#Huffman_threadin...
- 0815test 7y ago
  > Write-only, because only the functions (‘WORDS’) are named - no parameter names You could use lambda notation to name the parameters of a function, while still preserving postfix function application as in FORTH. This would effectively give you De Bruijn notation, in which named lambda was often denoted `[var] expr`. Though, ironically, De Bruijn is also known for his "nameless" De Bruijn indexes, which dispense with the very naming of function parameters, replacing these names with what are in effect references to positions on some abstract argument stack.
- astrobe_ 7y ago
  > Write-only, because only the functions (‘WORDS’) are named - no parameter names. Depends on who is the writer... > There are also no local variables in standard Forth Named locals variables are in the standard, as an optional extension. Because not everyone want them. > you have to push (and pop!) them from the separate return stack That's the main reason why the return stack is exposed to the programmer, yes, but there are other techniques like putting some of the data that are used throughout the program in (global) variables. you generally choose depending on how much simplification you gain and how much modularity you lose etc. > Accessing parameters is done by manipulating the stack, which makes the code opaque after a year or so Depends on how you write and comment. > Named constants and variables are all global. So, it is very difficult for a team to use Standard Forth as vocabularies to isolate functions, constants, and variables that is supposed to help with name clashes. Many variants like Retro have some sort of namespace mechanism. Did you actually use Forth in a team context? > These failings could be at least partly forgiven if Forth was fast. But it isn’t, because most words are short and all the stack manipulations are done with subroutine calls Not a problem, because you design your programs to minimize stack juggling. Less overhead, more readable, one stone, two birds. My dialect which uses very naive subroutine threading (it just executes lists of function pointers) can rival with Lua (non JIT) on certain tasks because my Forth doesn't spend its time doing useless stuff like looking up an hash table. The speed of Forth is not in its bytecode interpreter. It's in the simplifications it encourages. > It’s possible to write an inlining, optimizing compiler, but then the simple layout of code in memory is lost, and quick introspection using a memory dump becomes nearly impossible I have written a few decades such a thing for the 8086, and I would say the lack of introspection was never a problem. When you write such a system, the hex machine codes sticks quickly in your head. I think I wrote a disassembler for the lulz, but an hex dump was probably my main "introspection" tool. > I wrote a Forth a few decades ago I wrote several Forth systems in the last few decades. The latest one I wrote is my goto-tool and serves me almost daily.
kazinator 7y ago
> Lisp-level metaprogramming facilities Not even close. Rather more like macro-assembler-level metaprogramming facilities.

RodgerTheGreat 7y ago

It's also important to observe that Forth's approach to metaprogramming is very powerful, but completely different from Lisp's approach. It's not just another retread of the same ideas. CREATE...DOES>, immediate words, parsing words, fancy tricks with the rstack and other fun Forth stuff has at best very loose analogs in Lisp macros.

DennisP 7y ago
Where could I get a good tutorial on Forth metaprogramming?
- RodgerTheGreat 7y ago
  I think the late J.V. Noble's "A Beginner's Guide to Forth" does a good job introducing the language and touching on some metaprogramming features. Near the end he demonstrates a library which extends the language to support infix math expressions (a "FORTRAN") to make scientific computing more convenient. https://www.taygeta.com/fsl/docs/551.jvn.fall01/primer.htm#create https://www.taygeta.com/fsl/docs/551.jvn.fall01/primer.htm#c...

wrycoder 7y ago

Write-only, because only the functions (‘WORDS’) are named - no parameter names. There are also no local variables in standard Forth, you have to push (and pop!) them from the separate return stack. Accessing parameters is done by manipulating the stack, which makes the code opaque after a year or so. Named constants and variables are all global. So, it is very difficult for a team to use, since most of the legibility of software comes from insightfully selected names. Two thirds of those names, at least, are missing in Forth. Like assembler, Forth is untyped. These failings could be at least partly forgiven if Forth was fast. But it isn’t, because most words are short and all the stack manipulations are done with subroutine calls. It’s possible to write an inlining, optimizing compiler, but then the simple layout of code in memory is lost, and quick introspection using a memory dump becomes nearly impossible. But, it is a neat tool to bootstrap a working system quickly on new, embedded hardware with limited resources. Definitely a black belt tool for lightweight systems written by a single person. Hard on maintenance programmers. See Jonesforth for a tutorial example. I wrote a Forth a few decades ago. The insight gained reminds me of Nand2tetris, but the latter is far more mainstream.

szemet 7y ago
all the stack manipulations are done with subroutine calls This can have an advantage: one can stuff much more code (and functionality) in a very memory limited system (e.g. smart cards), especially with WORDS compression: "Huffman threaded code is one of the most compact representations known for a computer program" https://en.wikipedia.org/wiki/Threaded_code#Huffman_threading https://en.wikipedia.org/wiki/Threaded_code#Huffman_threadin...
0815test 7y ago
> Write-only, because only the functions (‘WORDS’) are named - no parameter names You could use lambda notation to name the parameters of a function, while still preserving postfix function application as in FORTH. This would effectively give you De Bruijn notation, in which named lambda was often denoted `[var] expr`. Though, ironically, De Bruijn is also known for his "nameless" De Bruijn indexes, which dispense with the very naming of function parameters, replacing these names with what are in effect references to positions on some abstract argument stack.
astrobe_ 7y ago
> Write-only, because only the functions (‘WORDS’) are named - no parameter names. Depends on who is the writer... > There are also no local variables in standard Forth Named locals variables are in the standard, as an optional extension. Because not everyone want them. > you have to push (and pop!) them from the separate return stack That's the main reason why the return stack is exposed to the programmer, yes, but there are other techniques like putting some of the data that are used throughout the program in (global) variables. you generally choose depending on how much simplification you gain and how much modularity you lose etc. > Accessing parameters is done by manipulating the stack, which makes the code opaque after a year or so Depends on how you write and comment. > Named constants and variables are all global. So, it is very difficult for a team to use Standard Forth as vocabularies to isolate functions, constants, and variables that is supposed to help with name clashes. Many variants like Retro have some sort of namespace mechanism. Did you actually use Forth in a team context? > These failings could be at least partly forgiven if Forth was fast. But it isn’t, because most words are short and all the stack manipulations are done with subroutine calls Not a problem, because you design your programs to minimize stack juggling. Less overhead, more readable, one stone, two birds. My dialect which uses very naive subroutine threading (it just executes lists of function pointers) can rival with Lua (non JIT) on certain tasks because my Forth doesn't spend its time doing useless stuff like looking up an hash table. The speed of Forth is not in its bytecode interpreter. It's in the simplifications it encourages. > It’s possible to write an inlining, optimizing compiler, but then the simple layout of code in memory is lost, and quick introspection using a memory dump becomes nearly impossible I have written a few decades such a thing for the 8086, and I would say the lack of introspection was never a problem. When you write such a system, the hex machine codes sticks quickly in your head. I think I wrote a disassembler for the lulz, but an hex dump was probably my main "introspection" tool. > I wrote a Forth a few decades ago I wrote several Forth systems in the last few decades. The latest one I wrote is my goto-tool and serves me almost daily.

kazinator 7y ago

> Lisp-level metaprogramming facilities Not even close. Rather more like macro-assembler-level metaprogramming facilities.