-al (--Al_Petrofsky) wrote:
> The proposed syntax fixes the parenthesis complexity
for fixed-arity
> cases, but it clearly still suffers from parenthesis complexity in
the
> variable-arity case.
It certainly does.
> As proof of this, I offer the fact that the
> syntax's own designer screwed up the parentheses in two out of three
> of the examples given for variable-arity clauses:
Sounds convincing. Luckily, the rubbish I wrote throws a "bad syntax"
in the LET
because neither (values . xs) nor (values)
match the <binding spec> I gave. ;-)
The mistakes were unintentional; thanks
for pointing them out.
> To avoid that mentally taxing triple-open-paren,
you could use a
> keyword named DOT rather than VALUES, with a syntax like so:
Good suggestion; takes down a mental
block I had: Of course I thought about having a
syntax of the form (let ((x1 x2 . x3+
(foo))) body), but this quickly came to a dead end called
(let ((. xs (foo))) body). At this point
I abandonned this line of thinking, maybe too early.
> I don't think you need a special case for exactly
zero values, because
> that's a fixed-arity case. Why not allow this?:
>
> (let ((<zero-valued-expression>)) <body>)
My main problem with this is the "but
what happens if it does goes wrong"-aspect.
The current syntax might not be the
most concise of all, but it is designed to let
LET choke on the most common mistakes
immediately (see above.)
Now with allowing zero variables in
a <binding spec> this cannot be accomplished.
For example, both (let (((for-each foo
(bar)))) body) and (let ((for-each foo (bar))) body)
are syntactically correct, but the first
just executes (for-each foo (bar)) whereas the
second binds for-each and foo to the
two values delivered by (bar).
Assume the first meaning was intended,
the error will probably manifest itself at
the moment (bar) fails to deliver exactly
two values to its continuation. Unless it
does, in which case the error must manifest
itself much further downstream
from the fact that foo never got called.
In order to avoid this sort of expensive
typos, I decided to propose a more
verbose syntax to begin with.
Sebastian.