3 ms·

My biggest problem with Forth is that you simply cannot start reading a program at an arbitrary point because you only have few valid entry points where you kno

My biggest problem with Forth is that you simply cannot start reading a program at an arbitrary point because you only have few valid entry points where you know that the stack is empty. Otherwise you just have no idea what's going on. This is where it differs from languages which try to guard the scope, but is, in a way similar to the problems created by violating the locality of the problem by using global variables. I feel like Forth might have evolved to mitigate this problem (as well as many similar ones, like not needing to specify the number or names of arguments to the subroutines, or not really having much structure to the routines that can be expressed through something like paired delimiters or indentation...) but, unfortunately, it didn't. Or, maybe I never found any descendants that would take the language further towards implementing some of the more modern ideas about how to structure large programs.

version_five 4y ago
I've only dabbled in forth so I'm not the right one to answer - but I just want to mention there are other stack based or concatenative languages like Factor and Joy that have had a lot of work put into them. From what I recall they feel like they were created and maintained by somewhat eccentric people... they may have put more thought into the problems you mention
- ahefner 4y ago
  In Factor the stack effects are static and annotated.
- crabbone 4y ago
  That's interesting. I'd have to try to find out more about these. Thanks!
- int_19h 4y ago
  They are also generally not as low-level as Forth, and thus don't have the same "easy to port to a completely new arch from scratch" thing going for them.
adastra22 4y ago
Many forths have type annotations for function definitions, summarizing the cumulative stack effects. In some cases these are rigorously enforced by the compiler.
- benhoyt 4y ago
  They're not really type annotations (because Forth is still basically untyped), but stack effect annotations. They're just a comment in parentheses that tells human readers of the code how many items are consumed/produced and (very roughly) what type they are: : SQUARE ( n1 -- n2 ) DUP * ; I've never run into any checkers for these comments -- though https://stackoverflow.com/a/40321950/68707 https://stackoverflow.com/a/40321950/68707 indicates that checkers may exist. For example, Gforth (GNU Forth), one of the most popular and full-fledged Forth compilers doesn't do this.
  - TapamN 4y ago
    StrongForth (http://www.arestlessmind.org/2009/02/03/intro.html http://www.arestlessmind.org/2009/02/03/intro.html) is a statically typed Forth that checks (and requires!) the annotations. It traces how the stack changes after every operation, and guarantees that every function is passed the correct number and types of parameters, and leaves the correct parameters on the stack when it returns. It's impossible to underflow the stack, and overflows are as likely as in C/C++/etc. To do this, there are some limitations on how the stack can be used compared to regular Forth. (For example, both sides of an IF/ELSE must leave the same number of items on the stack with the same types, but they can have different values. An IF without an ELSE can never change the depth of the stack or what types are on it, since the implicit, empty ELSE side says that the stack doesn't change.) This generally isn't a huge problem, as the things you can't do in StrongForth are usually not such a good idea from a maintenance perspective in regular Forths.

version_five 4y ago

I've only dabbled in forth so I'm not the right one to answer - but I just want to mention there are other stack based or concatenative languages like Factor and Joy that have had a lot of work put into them. From what I recall they feel like they were created and maintained by somewhat eccentric people... they may have put more thought into the problems you mention

ahefner 4y ago
In Factor the stack effects are static and annotated.
crabbone 4y ago
That's interesting. I'd have to try to find out more about these. Thanks!
int_19h 4y ago
They are also generally not as low-level as Forth, and thus don't have the same "easy to port to a completely new arch from scratch" thing going for them.

adastra22 4y ago

Many forths have type annotations for function definitions, summarizing the cumulative stack effects. In some cases these are rigorously enforced by the compiler.

benhoyt 4y ago
They're not really type annotations (because Forth is still basically untyped), but stack effect annotations. They're just a comment in parentheses that tells human readers of the code how many items are consumed/produced and (very roughly) what type they are: : SQUARE ( n1 -- n2 ) DUP * ; I've never run into any checkers for these comments -- though https://stackoverflow.com/a/40321950/68707 https://stackoverflow.com/a/40321950/68707 indicates that checkers may exist. For example, Gforth (GNU Forth), one of the most popular and full-fledged Forth compilers doesn't do this.
- TapamN 4y ago
  StrongForth (http://www.arestlessmind.org/2009/02/03/intro.html http://www.arestlessmind.org/2009/02/03/intro.html) is a statically typed Forth that checks (and requires!) the annotations. It traces how the stack changes after every operation, and guarantees that every function is passed the correct number and types of parameters, and leaves the correct parameters on the stack when it returns. It's impossible to underflow the stack, and overflows are as likely as in C/C++/etc. To do this, there are some limitations on how the stack can be used compared to regular Forth. (For example, both sides of an IF/ELSE must leave the same number of items on the stack with the same types, but they can have different values. An IF without an ELSE can never change the depth of the stack or what types are on it, since the implicit, empty ELSE side says that the stack doesn't change.) This generally isn't a huge problem, as the things you can't do in StrongForth are usually not such a good idea from a maintenance perspective in regular Forths.