Open nmorse opened 5 years ago
It doesn't have to be infix, but the syntax should allow to make arbitrary trees of composition and concatenation. For example, using s-expressions: (comp (conc sum len) div)
.
Personally I find the infix style very convenient, especially considering that whitespace can be also thought as an infix operator.
[sum len] conc div
might be the post-fix version of your example?
I am playing with my own version of stack-based programming -- Pounce . Up to this point, I have been committed to post-fix consistency (to see how far a purely post-fix syntax can be taken), but the stack shuffling is a blocker to code readability.
You make me realize that, yes, at the (rotten) core of a post-fix lang is the in-fix operator whitespace for functional composition.
I am thinking of either breaking post-fix "purity" by having two in-fix ops, or breaking point-free and naming some local vars.
[sum len] conc div
It looks like conc
is an ordinary function. But in my model concatenation is on the same level with the composition.
I am thinking of either breaking post-fix "purity" by having two in-fix ops, or breaking point-free and naming some local vars.
Or you can do both, like in Conc: https://suhr.github.io/wcpl/intro.html
Thanks for discussing these ideas with me, it may take me awhile to find the time to really read though your 'intro' post. After skimming over it I am wondering if there is an implementation of Conc?
I started it, but right now I don't have enough time to turn it into something usable.
You can also take a look at the conc predecessor. And for a draft of the operation semantics, see [opcalg].
Regarding
https://suhr.github.io/papers/calg.html
I follow your reasoning and arguments for an intuitive way to reduce stack shuffling. Comma may be a very good solution, but I am thinking that 'if this was introduced to Joy, it would stick out as the only in-fix operator in the whole language." Does what you propose ( a Comma operator ) necessarily need to be an in-fix operator?