[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: what about dropping rest-lists?
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