Home » forums » LtU Forum

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?

By xieyuheng at 2023-09-24 03:47 | LtU Forum | previous forum topic | next forum topic | other blogs | 13972 reads

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.

By James McCartney at Sat, 2023-10-07 14:30 | login or register to post comments

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

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

By James McCartney at Sat, 2023-10-07 14:31 | login or register to post comments

How about prefix notation?

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

By Ivan V. at Tue, 2023-10-10 14:39 | login or register to post comments

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.

By Ray Dillinger at Tue, 2023-10-10 16:16 | login or register to post comments

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...

By shap at Sun, 2023-11-12 01:11 | login or register to post comments

Prefix languages without

Prefix languages without delimiters are just as valid, but also just as opaque, as postfix languages without delimiters...

Except in certain higher-order applicative languages, where all arities are one. Though a reasonable case can be made that f(a, b c) should be read as an application of "f" to "(a, b, c)", where comma is a left-associative infix operator and the parens serve to disambiguate precedence.

By shap at Sun, 2025-03-23 02:54 | login or register to post comments