
Pantagruel: An Unambiguous, Undefined Program Specification Language - crux
https://hexdocs.pm/pantagruel/readme.html
======
egypturnash
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...](https://ebooks.adelaide.edu.au/r/rabelais/francois/r11g/book1.13.html)

~~~
taneq
What did I just read? O.o

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

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

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

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

------
AnthonBerg
I’m interested.

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

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

