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

Re: what about dropping rest-lists?

This page is part of the web mail archives of SRFI 71 from before July 7th, 2015. The new archives for SRFI 71 contain all messages, not just those from before July 7th, 2015.

On 5/16/05, Neil W. Van Dyke <neil@xxxxxxxxxxxxxxx> 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