The drawback is that building an AST now requires a symbol table and resolving imports, possibly performing type inference and whatnot. It constitutes a higher barrier for various types of tooling. You really want your programming language to avoid becoming context-sensitive in that way.
It’s similar for the human reader: The examples are only intelligible to the reader incidentally, due to the names used and some natural-text conventions. In the general case, you have a seemingly random token sequence where you have no idea what binds to what, without looking up the type definitions or having an IDE present the expression in some structured way again.
Furthermore, in typical code you don’t have the case of constant values so often. You’ll rather have things like:
nextYear thisMonth.previous() lastDayOf(thisMonth.previous())
Double.parse(speedInput) m/s
startPos to (startPos + length - 1)
Schedule contacts.select(contactId) inputForm.getDateTime()
What if these were real, type-safe expressions in Java:
2025 July 19 // → LocalDate
300M m/s // → Velocity
1 to 10 // → Range<Int>
Schedule Alice Tues 3pm // → CalendarEvent
That's the idea behind binding expressions — a compiler plugin I built to explore what it would mean if adjacency had operator semantics. It lets adjacent expressions bind based on their static types, forming new expressions through type-directed resolution.
I don't think this is useful in complex situations/expressions. Structure has to be encoded in the same place as meaning somehow. Natural language does it by using an extraordinarily large set of signifiers. That's not feasible for a formal language.
You could of course affix all lemmata with structural
information, as free word order languages do, but that's introducing syntactic structure via the backdoor.
Mathematica has Infix [0], which expresses the adjacency with a ~ (because Mathematica reserves pure blankspace for multiplication). But it works fine to do eg. `"hello"~StringJoin~" world"`; I was always surprised we could only have the predefined operators in many other languages and we couldn't define our own.
This seems like a great attempt. I would be worried about how much parsing and backtracking might be required to infer the infix precedence in a totally general system (like garden-path sentences[1]) or actually ambiguous parse trees (which is cured by adopting some rule like right precedence and parens, but what rule you pick makes some 'natural language' constructions work over others).
Similarly, Agda has a well-typed mixfix operator syntax – you define a function like (_foo_bar_baz) and can automatically write "X foo Y bar Z baz". It does mean that the operator parser has to be extensible at runtime, but it's not a huge cost for a dependently-typed language.
Sorry for this sounds absurd, but with diffusion language models, who generate text non-linearly (from the few that I get, they relate terms without a simpler order), I wonder if new syntactic ideas will come up.
An old paper on the expressiveness of the programming languages [1] had to add an implicit binary operator into whitespace to make Haskell not be ten times more expressive than most imperative languages.
So, yes, it can be done and it was done. Yes, expressiveness rises. No, reading comprehension of such languages does not suffer. Yes, it has to have a lot of scaffolding.
No, stack languages can’t achieve this as described.
If you added a function to the examples, you could do a few of them, e.g.:
2025 July 19 date
299.8 M m / s velocity
But even this breaks down when you get to something like “Meet Alice Tuesday at 3pm”. Sure, you could contort things to make it resemble the concept, but it’d be a stretch at best.
The drawback is that building an AST now requires a symbol table and resolving imports, possibly performing type inference and whatnot. It constitutes a higher barrier for various types of tooling. You really want your programming language to avoid becoming context-sensitive in that way.
It’s similar for the human reader: The examples are only intelligible to the reader incidentally, due to the names used and some natural-text conventions. In the general case, you have a seemingly random token sequence where you have no idea what binds to what, without looking up the type definitions or having an IDE present the expression in some structured way again.
Furthermore, in typical code you don’t have the case of constant values so often. You’ll rather have things like:
What if these were real, type-safe expressions in Java:
That's the idea behind binding expressions — a compiler plugin I built to explore what it would mean if adjacency had operator semantics. It lets adjacent expressions bind based on their static types, forming new expressions through type-directed resolution.Details here: https://github.com/manifold-systems/manifold/blob/master/doc...
I don't think this is useful in complex situations/expressions. Structure has to be encoded in the same place as meaning somehow. Natural language does it by using an extraordinarily large set of signifiers. That's not feasible for a formal language.
You could of course affix all lemmata with structural information, as free word order languages do, but that's introducing syntactic structure via the backdoor.
Mathematica has Infix [0], which expresses the adjacency with a ~ (because Mathematica reserves pure blankspace for multiplication). But it works fine to do eg. `"hello"~StringJoin~" world"`; I was always surprised we could only have the predefined operators in many other languages and we couldn't define our own.
This seems like a great attempt. I would be worried about how much parsing and backtracking might be required to infer the infix precedence in a totally general system (like garden-path sentences[1]) or actually ambiguous parse trees (which is cured by adopting some rule like right precedence and parens, but what rule you pick makes some 'natural language' constructions work over others).
[0] https://reference.wolfram.com/language/ref/Infix.html
[1] https://en.wikipedia.org/wiki/Garden-path_sentence
Similarly, Agda has a well-typed mixfix operator syntax – you define a function like (_foo_bar_baz) and can automatically write "X foo Y bar Z baz". It does mean that the operator parser has to be extensible at runtime, but it's not a huge cost for a dependently-typed language.
Sorry for this sounds absurd, but with diffusion language models, who generate text non-linearly (from the few that I get, they relate terms without a simpler order), I wonder if new syntactic ideas will come up.
An old paper on the expressiveness of the programming languages [1] had to add an implicit binary operator into whitespace to make Haskell not be ten times more expressive than most imperative languages.
[1] https://www.researchgate.net/publication/2743686_Are_Ours_Re...
So, yes, it can be done and it was done. Yes, expressiveness rises. No, reading comprehension of such languages does not suffer. Yes, it has to have a lot of scaffolding.
Maybe with a Java string templates:
Congratulations, you reinvented yet another stack language.
No, stack languages can’t achieve this as described.
If you added a function to the examples, you could do a few of them, e.g.:
But even this breaks down when you get to something like “Meet Alice Tuesday at 3pm”. Sure, you could contort things to make it resemble the concept, but it’d be a stretch at best.