[racket] Splicing `values' in-place

Matthias,

On Fri, Jul 12, 2013 at 7:36 PM, Greg Hendershott <greghendershott at gmail.com
> wrote:

> >> Then why not return lists instead of values?
> > Error checking.
>

Well, expecting a number and receiving a list (instead of several values)
is not very different from expecting a number and receiving a string.
In both cases the user didn't read the specs correctly.
But sure, the more checks we can have, the better.

I suspect it has more to do with optimization (once again), than error
checking.

> See Dybvig's paper,

Thanks for the reference, this is very informative and well written.
The performance checks seem to be quite tailored toward `values', and there
are cases where what you really need to do is to handle the returned values
as a list.
I read it quickly (for that first time) but the "error handling" part does
not seem to be the main reason.

Greg,


> Although nowadays we have match-define and friends.
>
> (define-values      (a b c) (return-3-values))
> (match-define  (list a b c) (return-3-element-list))
>
> Both would error appropriately.
>

Probably those cases are not the ones with problems.

I guess one of the worst cases would be if you call:
(foo (bar 3))
where (bar 3) returns a list, but at some point its implementation changes
and returns both a list and a string, encapsulated as multiple values in a
list.
Then foo will not error correctly and it may be non-trivial to find the bug.
But of course this is a backward-incompatible change so that's the kind of
problem you can expect from such a change.

A related problem is if you misread the docs and consider that `bar'
returns `(list 3 3 3)' whereas it actually returns multiple values `(list
"something" (list 3 3 3))'.

An intermediate solution would be that `values' returns indeed a `list',
but (somehow) tagged with 'values, so that one can now it's suppose to mean
a multiple return value but can still be handled with all the tools from
`list'.

Thanks to all other repliers for their interesting comments.

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130715/a6213822/attachment.html>