I did a more systematic analysis of
the requirements and the alternatives.
It turned out that the real problem
is not the presence of the VALUES-
syntax, but the limits of the "just
list the variables"-syntax.
As a logical conclusion I will stretch
the "list the variables"-syntax to
include the "."-notation in
the cases it can cover (except the "no values"
case due to syntactic robustness), and
leave the VALUES-syntax in
for full generality and uniformity.
This design reduces the cases in which
VALUES *must* be used to
a) no values at all and
b) a single variable receiving the list
of all values.
...hopefully there will be a new version
of the SRFI, soon.
Sebastian.
----
Dr. Sebastian Egner
Senior Scientist Channel Coding & Modulation
Philips Research Laboratories
Prof. Holstlaan 4 (WDC 1-051, 1st floor, room 51)
5656 AA Eindhoven
The Netherlands
tel: +31 40 27-43166 *** SINCE 10-Feb-2005
***
fax: +31 40 27-44004
email: xxxxxx@philips.com
srfi-71xxxxxx@srfi.schemers.org
17-05-2005 14:26
To:
Sebastian Egner/EHV/RESEARCH/xxxxxx@PHILIPS
cc:
srfi-71@srfi.schemers.org
Subject:
Re: what about dropping rest-lists?
Classification:
Sebastian Egner <xxxxxx@philips.com>
wrote at 2005-05-17T10:51:31+0200:
> And if you really need the rest-list thing (the day will come),
> the meaning will at least be obvious.
How about a keyword named "rest", with parens around the keyword
and
variable identifier? The parens emphasize to human readers that the
"rest" name is in a keyword position and therefore should not
be
mistaken for a variable identifier?
(let ( (a b c d (values 1 2 3 4)) ) c)
;=> 3
(let ( (a b (rest x) (values 1 2 3 4)) ) x) ;=>
(3 4)
(let ( ((rest x) (values 1 2 3 4)) ) x) ;=>
(1 2 3 4)
(let ( (a b (rest x) (values 1 2 3 4)) ) x)
;=> (3 4)
(let ( (a b (rest rest) (values 1 2 3 4)) ) rest) ;=>
(3 4)