Oou, this is an interesting one. As I read, it appears more and more clear that this is more LISP than it is Forth. What I find a bit awkward about the language is it appears to be not great in either realm, but in a weird in-between. I was looking forward to seeing example programs but there were none…
The academic examples, such as Y combinator, all leverage LISP/Lambda Calculus powers to achieve. This is the telling sign to me that this is more LISP/LC than Forth. Y combinator in Forth doesn’t make much sense to do (it can be done, just really you never would.)
I look forward to how the author further evolves Forsp! I would like to see them lean more toward a Forth-y variant for sure.
Minor notes:
Stack Languages are Confusing
After spending a decent amount of time with Forth I think this is a myth. Stack languages are just different. Once you work with one, you begin to realize maybe everything else is confusing! I think a more appropriate subtitle would be “Stack Languages are Confusing [at first]”.
; NOTE: “cswap” is a “conditional swap” primitive.
Seeing this used to implement if I think is a bit of an indirection. if itself is a misnomer, really all if are just conditional branches. I’m not sure what it proves, other than shown as an implementation of if.
you begin to realize maybe everything else is confusing
100% this - you start to question why everything else is so complicated and why you’re doing half of it when it doesn’t blit the result to the screen. Stack languages make me happy in that regard. Also, did we used to talk in the #Forth IRC?
Those examples still represent typical academic examples. They are really nice for getting a sense of the edges of the language quickly, but other usage is left to the imagination!
At least syntactically speaking, this feels similar to my own min concatenative language, in the usage of parenthesis for quoting and “sigils” for certain special forms. Obviously it is probably more refined and better-implemented, but the resemblance is interesting at least.
I was a bit confused by that, since Forths normally (almost always?!) have (global) variables, as programing without indirection is… Just assembly.
(Digression follows.) Now, Chuck Moore said local variables are dangerous, but multithreaded Forths require non-global variables, so it does get more complicated. But that global is a misnomer, as they’re typically statically allocated with scope from declaration until that wordlist is no longer visible (i.e. the scope normally ends) and local isn’t what we’d intuit from other paradigms, but means it’s allocated to the stack.
Forth variables aren’t distinguished by scope, but lifetime! For how long is this variable allocated?
There is a community of people who design languages that have a stack (like Forth) but which also embrace the ideas behind functional programming (which is decidedly not like Forth).
These languages are called “concatenative languages”. I find this term useful for languages that distance themselves from Chuck Moore’s low-level programming aesthetic wherein “local variables are dangerous”.
The first so-called concatenative language was Joy by Manfred von Thun, which was not inspired by Forth despite a superficial syntactic similarity. Instead, Joy was inspired by FP, a pure functional language by John Backus, who also gave us Fortran and BNF (Backus-Naur Form). In FP, the function composition operator f∘g is so central to programming that Manfred decided to make a language where function composition is written in left-to-right evaluation order as juxtaposition (g f).
I prefer to think of Forsp as a concatenative language, despite the name.
Chuck did say that, but starting with colorForth he sort-of changed his mind - i.e. the a and b locals which Moore uses in OKAD. Here’s a previous discussion where I shared this information, and now I want to say the source for Chuck changing his mind slightly on locals was a Forth Day speech where he talks about a Forth that has no stack but uses CPU registers… but don’t quote me on that…
Dangerous is a strong word, but local variables are often a Forth code smell. If you’re writing words that require more than simple stack manipulations you can follow in your head, to the point where you need identifiers for the data that’s immediately available to you and you can’t operate on it with stack operators, you’re probably writing a word that’s too complex.
I’ve been playing in this realm for a bit, so it’s fun to see others making similar, yet, different connections. My most recent prototype, which isn’t even as complete as the linked post, has a lot more parens, but in many cases they aren’t necessary. They are necessary for things like local bindings (#(TOS1 TOS0) .... ) and in “special forms” like if, def… source.
In forsp, the force operator is similar to the i operator in joy. In joy, you can eval an arbitrarily computed list. In forsp, it seems like the thunking operator can’t arbitrarily create thunks at runtime, which means you might be able to compile this effeciently. Definitely want to look at this more. It’s right up my alley.
This is somewhat validating to see - it seems very similar to my own “discovery” (albeit more concise and well thought out), even down to if being implemented in terms of a conditional swap. endif being the operative word is a nice touch!
Oou, this is an interesting one. As I read, it appears more and more clear that this is more LISP than it is Forth. What I find a bit awkward about the language is it appears to be not great in either realm, but in a weird in-between. I was looking forward to seeing example programs but there were none…
The academic examples, such as Y combinator, all leverage LISP/Lambda Calculus powers to achieve. This is the telling sign to me that this is more LISP/LC than Forth. Y combinator in Forth doesn’t make much sense to do (it can be done, just really you never would.)
I look forward to how the author further evolves Forsp! I would like to see them lean more toward a Forth-y variant for sure.
Minor notes:
After spending a decent amount of time with Forth I think this is a myth. Stack languages are just different. Once you work with one, you begin to realize maybe everything else is confusing! I think a more appropriate subtitle would be “Stack Languages are Confusing [at first]”.
Seeing this used to implement
ifI think is a bit of an indirection.ifitself is a misnomer, really allifare just conditional branches. I’m not sure what it proves, other than shown as an implementation ofif.100% this - you start to question why everything else is so complicated and why you’re doing half of it when it doesn’t blit the result to the screen. Stack languages make me happy in that regard. Also, did we used to talk in the #Forth IRC?
There are examples here: https://github.com/xorvoid/forsp/tree/main/examples
Those examples still represent typical academic examples. They are really nice for getting a sense of the edges of the language quickly, but other usage is left to the imagination!
At least syntactically speaking, this feels similar to my own min concatenative language, in the usage of parenthesis for quoting and “sigils” for certain special forms. Obviously it is probably more refined and better-implemented, but the resemblance is interesting at least.
I love min! That is all.
That it is, I think I’ve added them to every stack language I’ve made, heh
A thing I’ll need to check later is how Forsp nests environments, there’s a lot of potential hiccups there for programming in the large
I was a bit confused by that, since Forths normally (almost always?!) have (global) variables, as programing without indirection is… Just assembly.
(Digression follows.) Now, Chuck Moore said local variables are dangerous, but multithreaded Forths require non-global variables, so it does get more complicated. But that global is a misnomer, as they’re typically statically allocated with scope from declaration until that wordlist is no longer visible (i.e. the scope normally ends) and local isn’t what we’d intuit from other paradigms, but means it’s allocated to the stack.
Forth variables aren’t distinguished by scope, but lifetime! For how long is this variable allocated?
I also want to plug LispE which combines Lisp with Array languages: https://github.com/naver/lispe
There is a community of people who design languages that have a stack (like Forth) but which also embrace the ideas behind functional programming (which is decidedly not like Forth).
These languages are called “concatenative languages”. I find this term useful for languages that distance themselves from Chuck Moore’s low-level programming aesthetic wherein “local variables are dangerous”.
The first so-called concatenative language was Joy by Manfred von Thun, which was not inspired by Forth despite a superficial syntactic similarity. Instead, Joy was inspired by FP, a pure functional language by John Backus, who also gave us Fortran and BNF (Backus-Naur Form). In FP, the function composition operator
f∘gis so central to programming that Manfred decided to make a language where function composition is written in left-to-right evaluation order as juxtaposition (g f).I prefer to think of Forsp as a concatenative language, despite the name.
Chuck did say that, but starting with colorForth he sort-of changed his mind - i.e. the
aandblocals which Moore uses in OKAD. Here’s a previous discussion where I shared this information, and now I want to say the source for Chuck changing his mind slightly on locals was a Forth Day speech where he talks about a Forth that has no stack but uses CPU registers… but don’t quote me on that…Why did he regard local variables as dangerous?
Dangerous is a strong word, but local variables are often a Forth code smell. If you’re writing words that require more than simple stack manipulations you can follow in your head, to the point where you need identifiers for the data that’s immediately available to you and you can’t operate on it with stack operators, you’re probably writing a word that’s too complex.
I’ve been playing in this realm for a bit, so it’s fun to see others making similar, yet, different connections. My most recent prototype, which isn’t even as complete as the linked post, has a lot more parens, but in many cases they aren’t necessary. They are necessary for things like local bindings
(#(TOS1 TOS0) .... )and in “special forms” likeif,def… source.In forsp, the
forceoperator is similar to theioperator in joy. In joy, you can eval an arbitrarily computed list. In forsp, it seems like the thunking operator can’t arbitrarily create thunks at runtime, which means you might be able to compile this effeciently. Definitely want to look at this more. It’s right up my alley.This is somewhat validating to see - it seems very similar to my own “discovery” (albeit more concise and well thought out), even down to
ifbeing implemented in terms of a conditional swap.endifbeing the operative word is a nice touch!