5 ms·

Wait! Is core Forth smaller than core Scheme?

avmich 4y ago
If you think about garbage collection alone, you might guess...
deckard1 4y ago
Scheme is deceptive. I think R5RS was all of 50 pages or so. But try implementing quasiquotes, closures, lexical scoping, tail call optimization. Not to mention the trickier things of call/cc, dynamic-wind, hygienic macros. There is a surprising amount of complexity involved. Even if you do go with the simplest of GCs, which is probably stop-and-copy.
shrubble 4y ago
Much smaller in terms of code size and memory used, yes. A small Forth running in 2 kilobytes RAM is easily done.
tluyben2 4y ago
You can write a Forth-like in a few lines of a modern language and then keep expanding it. There are Forths for the smallest systems and challenges of minimal instruction set Forth, like [0]. The article [0] explains what people (and myself) are really happy about having this around: > Let's pretend I've wired the 68HC11 so that port A pin 01 controls an LED. I can't remember whether a 0 or a 1 turns it on and I'm not sure whether it works. I look in the data book and find that address zero is the port A data address. Although the LED only uses a single bit of port A I don't have anything else connected so I'll just set the whole byte on or off and see what happens. Without that, embedded work is far more annoying. And I do like the way it works; every so many years, I start implementing my own to figure out if it's really not possible to make something modern [1] (written to play around with Xamarin apps and ASP.NET servers without having to wait 9 hours for the compile & deploy to finish, so in the spirit of Forth indeed) with it which always falls over on stack manipulation, which gets incredibly annoying when programs grow; you waste so many instructions just to line up the stack correctly to execute a some more complicated word. We currently have a hybrid language (hopefully released this year) with datatypes, stack, (reactive) variables etc, but that is getting rather huge (for a Forth) and, because of other features we have, it's more like a Frankenlanguage, marrying Forth & Lisp... That works well but not anything usable in embedded or in the spirit of the original Forth, besides spelonking/scripting systems. [0] https://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html https://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html [1] https://gist.github.com/tluyben/16ee2645c4c8aed813005d51488d5c6a https://gist.github.com/tluyben/16ee2645c4c8aed813005d51488d...
- syntheweave 4y ago
  Forth semantics work nicely as unstructured glue, I've found. As you start getting into the weeds of algorithm design it becomes more of a puzzle. But that also makes sense, in a Forther context. The most Forth-like thing to do is not to start abstracting and imposing structure so that you can have a configurable algorithm, but to define down the problem to a table of static results, and thus complete the circle of "code is data". I believe Chuck Moore said something to the effect of Forth being in the workflow and mindset: once you have a problem defined to need that much complexity of automation, it's not a problem solved by Forth-the-language. Of course, Moore also has done some algorithmically complex things with Forth-the-language, so I might be off-base in that assessment.

If you think about garbage collection alone, you might guess...

Scheme is deceptive. I think R5RS was all of 50 pages or so. But try implementing quasiquotes, closures, lexical scoping, tail call optimization. Not to mention the trickier things of call/cc, dynamic-wind, hygienic macros. There is a surprising amount of complexity involved. Even if you do go with the simplest of GCs, which is probably stop-and-copy.

shrubble 4y ago

Much smaller in terms of code size and memory used, yes. A small Forth running in 2 kilobytes RAM is easily done.

tluyben2 4y ago

You can write a Forth-like in a few lines of a modern language and then keep expanding it. There are Forths for the smallest systems and challenges of minimal instruction set Forth, like [0]. The article [0] explains what people (and myself) are really happy about having this around: > Let's pretend I've wired the 68HC11 so that port A pin 01 controls an LED. I can't remember whether a 0 or a 1 turns it on and I'm not sure whether it works. I look in the data book and find that address zero is the port A data address. Although the LED only uses a single bit of port A I don't have anything else connected so I'll just set the whole byte on or off and see what happens. Without that, embedded work is far more annoying. And I do like the way it works; every so many years, I start implementing my own to figure out if it's really not possible to make something modern [1] (written to play around with Xamarin apps and ASP.NET servers without having to wait 9 hours for the compile & deploy to finish, so in the spirit of Forth indeed) with it which always falls over on stack manipulation, which gets incredibly annoying when programs grow; you waste so many instructions just to line up the stack correctly to execute a some more complicated word. We currently have a hybrid language (hopefully released this year) with datatypes, stack, (reactive) variables etc, but that is getting rather huge (for a Forth) and, because of other features we have, it's more like a Frankenlanguage, marrying Forth & Lisp... That works well but not anything usable in embedded or in the spirit of the original Forth, besides spelonking/scripting systems. [0] https://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html https://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html [1] https://gist.github.com/tluyben/16ee2645c4c8aed813005d51488d5c6a https://gist.github.com/tluyben/16ee2645c4c8aed813005d51488d...

syntheweave 4y ago
Forth semantics work nicely as unstructured glue, I've found. As you start getting into the weeds of algorithm design it becomes more of a puzzle. But that also makes sense, in a Forther context. The most Forth-like thing to do is not to start abstracting and imposing structure so that you can have a configurable algorithm, but to define down the problem to a table of static results, and thus complete the circle of "code is data". I believe Chuck Moore said something to the effect of Forth being in the workflow and mindset: once you have a problem defined to need that much complexity of automation, it's not a problem solved by Forth-the-language. Of course, Moore also has done some algorithmically complex things with Forth-the-language, so I might be off-base in that assessment.