What I mean in ML syntax, every function is a curried function of only one argument. So you don't know how many arguments a function has without looking up its type. In concatenative languages, this is similar, every function (with exception of special forms) is a function from stack to stack, and to see how many arguments it has you also have to look at its type.
I think concatenative syntax is in fact more elegant than ML syntax, since it also "curries" return values, and is evaluated in the same order as written.
Re:Why concatenative programming matters (2012)
by yakubin on Sunday July 17, 2022 @09:49AM
(#32126727)
If b is declared to be infix by default, then it will be an application of function b to arguments a and c though. So you need to know the symbol table anyway it seems.
Re:Why concatenative programming matters (2012)
by IHLayman on Sunday July 17, 2022 @09:33AM
(#32126612)
Haskell coders have to do this often enough that there is a token that does this grouping… f $ g x = f (g x), so the expression `a b c` is still a source for ambiguity.
Re:Why concatenative programming matters (2012)
by avgcorrection on Sunday July 17, 2022 @10:51AM
(#32127296)
`$` is an operator. There is no ambiguity (you might not know the precedence table but that doesn’t make it ambigious).
In ML, function application is left-associative, and therefore `a b c` always means `(a b) c`. It can’t mean `a (b c)`, even if that would fit the types.
The expression structure is therefore independent from the types in ML. You can parse the expression tree without a symbol table. In concatenative languages, on the other hand, you need to look up the types, or if the language is dynamically typed, the expression structure only manifests at runtime.