This involves a whole lot less ass-wiping[1] than I was expecting it to.

1: https://ebooks.adelaide.edu.au/r/rabelais/francois/r11g/book...

What did I just read? O.o

An excerpt from “Gargantua and Pantagruel”. It’s a classic of French literature!

I'm curious how the parsing must work because I can't unambiguously see how this line is parsed

fib x ← fib x − 1 + fib x − 2

Why is that parsed to behave correctly like

fib x ← fib (x − 1) + fib (x − 2)

And not,

fib x ← fib( x − 1 + fib ( x − 2 ))

Or even this, though it wouldn't produce a sane program

fib x ← fib ( x ) − 1 + fib ( x ) − 2

I think the idea is that something is ambiguous if it has more than one meaning. This language avoids the problem by having no meaning. It may be a very dry joke. I'm not sure.

I think to be fair I can't even claim the joke.

Yes, in the first place there's no defined semantics and thus no meaning.

It's also not particlarly appropriate to claim that the language is 'unambiguous'. The intention of the language is to create a notation that allows for the unambiguous expression of relations that would be ambiguous in English, that is, to present a logical or mathematical specification rather than a natural language one. So the ambiguity or lack thereof is entirely in the mind of the reader.

I do have a semantics in mind for it; I have thought about things like operator precedence and currying and stuff. And that matters because you want to be sure that the person reading the specification and the person writing it had the same thing in mind as far as the order of the marks on the page goes.

So there will hopefully be a much more concrete realization of those semantics in a way that still leaves wide open the question of expression evaluation. In other words, it should be an objective fact that `a b c` is evaluated as `a (b c)` - and indeed it is, because the program has parsing rules for function application - but the specifics of what it means to apply `b` to `c` will never be enforced or evaluated on the machine level.

---

In fact, the parent comment's example is a good one because `fib n - 1 + fib n - 2` would be parsed as `fib (n - (1 + (fib (n - 2))))` which is not the intended reading. Right now, that's fine, because it doesn't actually evaluate them. It just pretty prints them back out in the right order and trusts that if you didn't put parentheses there, then the intended meaning should be clear enough to the human reader.

So what, ultimately, will be the relationship between the parsing rules in the program and the semantic openness of the language? Similarly, if I've decided that the language should have implicit currying, such that `f a` where `f` is a function of two arguments, should resolve to a partially applied function of one argument - does that have any meaning aside from a sort of 'suggested reading'? One potential direction for things to evolve is that the language will consist of a set of rules which are enforced by the interpreter and will result in a syntax error if not followed, and a set of rules which are explained in the documentation as a suggested convention but enforced nowhere. In that case the question of something like function precedence is still an odd grey area where the parser does have rules associated with it, but the symbols can flow in and out of the parser without being affected by those rules.

The parser as described _only_ cares about identifiers; it has no concept of operator precedence, which is not required for its purpose.

I’m interested.

And: I’m still attempting to understand copatterns, but this is quite reminescent of copatterns. That’s all I have.

Finally someone who writes a proper and honest "Who would be interested in this?". Thanks.