Re: what about dropping rest-lists?

[Sebastian Egner <sebastian.egner@xxxxxxxxxxx>]

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

Indeed, it should.

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

In the end, it is a matter of taste.
I switched a number of times already before
submitting the SRFI, but what tilted
the scale in the end was the DEQUE example
(found in 'examples.scm'): The "un"-convention
modifies an English verb 
(to cons -> to uncons) and does not
express a conversion. After some time I
learned to like the "un"-convention,
and until now I had little reason for 
adding ...->values redundantly.

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

The main intention of this SRFI is a
little more ambitious than extending "let":
The main intention of this SRFI is integrating
multiple values smoothly into
the Scheme language. In other words,
there should be a (preferably small)
well-designed toolbox for dealing with
multiple values---and a turnkey way
of packing values into heap-allocated
data structures (and unpacking
again) is a natural part of that.

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

In case this SRFI would eventually find
it's way into Scheme, both points might change:
a) the decomposition ops do make life
easier, and hence,
b) they will be used more frequently.

If you look at Olin Shivers code for
sorting (e.g. in the Scheme 48 1.2 release)
you find that multiple values are used
frequently and consistently. Unfortunately,
the code is drenched in values/call-with-values.
[I am talking about things like 
'vector-util.scm': has-element/list-ref-or-default.]
Looking at the code more closely,
you will also find macros [e.g. let-vector-start+end
in 'sort-support-macs.scm']
that are ad hoc binding constructs for
solving a multiple value parameter
passing problem. Of course, all this
has to do with the fact that the code was
written long before tools for multiple
values (like receive) became standard.

Well, this SRFI provides a general alternative
solution for the parameter passing
problem, provided some operations like
unlist/values->list are included.

There is another, deeper, aspect to
"life made easiler": Right now data 
structures and types are defined in
terms of access functions, but often
all I need to do is decompose the record
entirely. So, consider the following
little syntax extension to SRFI 9 (define-record-type):

        (define-record-type
kons-pair (kons x y) kons? unkons)
        
where kons-pair is a descriptive name
for the new type, kons? is a type
predicate, kons is a binary constructor,
and unkons a deconstructor
delivering the values x and y to its
continuation. You really need a KAR
operation? Here it is: (lambda (p) (let
((x y (unkons p))) x)).

In fact, the DEQUE example from 'examples.scm'
of this SRFI simply
uses cons/uncons, but what I really
had in mind was 

        (define-record-type
deque (deque:make f r) deque? deque:unmake)

with the subsequent code unaltered.
You can decide for yourself if you
like this style of dealing with records
(it is not always appropriate) but it
can make life easier (and the code could
even be more efficient because
fewer type checks are executed.)

I did not include define-record-type
syntax into this SRFI because it is
beyond the scope of this SRFI for now,
but it crossed my mind. However,
I did not want to leave out *some* way
of decomposing data structures,
and there were just two obvious candidates...

Does this explanation satisfy you?

Sebastian.