[racket] Splicing `values' in-place

On Thu, Jul 11, 2013 at 08:23:01PM +0200, Laurent wrote:
> Ah that unfortunately explains a lot. Thank you Matthew for this
> explanation.
> It's too bad that one needs to throw away nice semantics for speed...
> 
> Neil's macro idea may then well be one of the best intermediate solutions
> then.
> 
> Jens, thanks for all the links, they are quite informative.
> Indeed, quite a number of people seem unhappy with `values'.
> 
> However, since I did not find an answer for the following, I will risk this
> anyway:
> Then why not return lists instead of values? Performance problem again?
> There would not be such a thing as "multiple return values" though, and one
> should not see them this way.

I think the multiple return values are a remnant of ancient LISP 
systems, where they happened to have a few registers left over to 
return values in.  The caller could just ignore the extra register 
contents unless special code was used to retrieve them.

But the feature has unfortunate implications for the language 
design, static checking, code comprehensibility, and so forth, as 
described in a previous post.

I'd avoid putting it in the language with a ten-foot pole.

Well, maybe specific syntax for splicing in extra arguments could be 
the tten-foot pole all these tools use to avoid touching it, but I've 
always thought it stinks.

> Several values returned in a list is just a list, i.e., a single return
> value. Then there are helpers to bind several values from a list, etc.
> No need for `apply-values' or `call-with-values', just use `apply'.
> Therefore returning `(list 1)' would of course be different from returning
> `1', but if you don't see them as multiple return values, it's not
> inconsistent.

Lists I understand.

> The type of the procedure  would tell what is returned anyway.
> Some languages like Python, PHP (and Matlab?) do that, and I find this more
> convenient than `values'.

Types could work,  But types are not static in Scheme.  As a language 
designer, I prefer static typing, so maybe I'm showing a prejudice 
here.

> A "problem" would then be quieter errors for multiple/single value
> mismatch, but I don't really see this one as important.
> I also don't see the need for a different data type like `sequences' as
> they call it in Jen's thread.
> 
> When I use `values', either I (have to) bind them directly to identifiers,
> or I turn them into a list of values to manipulate them otherwise.
> The above would make this much easier and simpler I suspect.
> 
> Laurent