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.