[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestion: nix VALUES in favor of DOT




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