Email list hosting service & mailing list manager

Suggestion: nix VALUES in favor of DOT Alpha Petrofsky (16 May 2005 22:01 UTC)
Re: Suggestion: nix VALUES in favor of DOT Neil W. Van Dyke (16 May 2005 22:20 UTC)

Suggestion: nix VALUES in favor of DOT Alpha Petrofsky 16 May 2005 22:01 UTC

The current draft of the srfi says:

  let-values suffers from "parenthesis complexity"

The proposed syntax fixes the parenthesis complexity for fixed-arity
cases, but it clearly still suffers from parenthesis complexity in the
variable-arity case.  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:

  The syntactic keyword values allows receiving all values as in (let
  ((values . xs) (foo x)) body). It also allows receiving no values at
  all as in (let ((values) (for-each foo list)) body).

Those should be (let (((values . xs) (foo x))) body) and (let
(((values) (for-each foo list))) body), according to the specification
given later in the srfi.

To avoid that mentally taxing triple-open-paren, you could use a
keyword named DOT rather than VALUES, with a syntax like so:

  (let ((a b dot c (unlist '(1 2 3 4)))) c)  =>  (3 4)

  (let ((dot x (unlist '(1 2 3 4)))) x)      =>  (1 2 3 4)

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

Here's some BNF:

  <binding spec> --> (<variable>* <expression>)
  <binding spec> --> (<variable>* dot <variable> <expression>)

Whether or not DOT would be the best choice of identifier for this, I
don't know.  Here are the identifiers I considered:

  dot
  rest
  &rest
  &
  rest=>
  stick-the-rest-of-the-values-into-this-variable-to-my-right=>
  =>

-al