On 5/16/05, Neil W. Van Dyke <xxxxxx@neilvandyke.org> wrote:
>
> The "values" keyword as a kludge to support rest-lists, however, strikes
> me as a syntactically ugly way to support an operation that I'd expect
> to use only rarely.
>

I agree with Neil here.

>From the document:

"An alternative naming convention for the decomposition operation
unlist is list->values, which is a more symmetrical with respecto to
its inverse operation list->values."

Is this correct? (not regarding the typos) Should the latter occurence
"list->values" be "values->list"?

"This symmetry ends, however, as soon as more complicated data
structures with other operations are involved. Then it becomes aparent
that the same data structure can support different decomposition
operations: A double-ended queue (deque) for example supports
splitting off the head and splitting of the tail; and neither of these
operations should be named deque->values. The un-convention covers
this in a natural way."

Could you (Sebastian) explain this a little? I understand that there are several
ways of decomposing complex data-structures into values, but for lists and
vectors, the way they are decomposed appears to be straightforward to me.
So I *would* think that ...->values might be more appropriate, but this is
probably a matter of taste...

I wonder if the decomposition operations (and "values->...") should be
dropped completely from this SRFI.
They do not really fit to the main intention of this SRFI (as I understand
it - mainly extzending "let") and look like being thrown in for good measure.
"uncons" is already provided by SRFI-1 ("car+cdr"), and the other
operations are seldom used and don't really make our life much easier
(IMHO).

cheers,
felix