A case study of concatenative v.s. applicative syntax design

I implemented a language a while ago.

Based on some feedback, I change it's syntax from concatenative:

https://github.com/cicada-lang/inet-cute

- Stack-based like forth.
- Simple and shorter code.
- Easy to do refactoring.

to applicative:

https://github.com/cicada-lang/inet-js

- JavaScript-like syntax.
- Using pattern matching to define interaction rule.
- Can use currying, because we have explicit parentheses.

But I am still not sure which is better.

What do you think?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

without knowing all word arities, you can't read postfix code

After having written a postfix language myself and using it for several years, I came to the conclusion that I wanted an infix syntax (or even sexprs). With postfix languages, you must know the arity of every operator in order to read the code. Someone who tries to read your code and does not know the arities of the functions you are using has no hope of figuring out what is going on.

What I loved about postfix was the style of interactive incremental programming. In this functional language I had, you could just keep appending words to transform the values on the stack, which in my language were lazy lists, usually of audio.

without knowing all word arities, you can't read postfix code

Sorry, it told me server error, try again. How do I delete?

How about prefix notation?

Well, there is yet another option to consider, if you like Lisps... the prefix notation.

That's all about the delimiters.

Prefix languages without delimiters ( <-- like these --> ) are just as valid, but also just as opaque, as postfix languages without delimiters : if you don't know the word arities you will be lost.

I like that parens allow variable arity. I think that improves general expressiveness. But delimiters like parens are typically the 'exceptions' that start bending languages away from pure concatenative or pure applicative paradigms, creating syntactic groupings that have special rules.

Also true for postfix

One could imagine a postfix RS-expr (reverse S-expression) language, presumably written as something like:

)a b cons(

OK. I'm joking by reversing the parens, but the result would be just as unambiguous as traditional S-expressions...