[racket] Splicing `values' in-place

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




On Thu, Jul 11, 2013 at 5:18 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> To elaborate on "currently not possible" (because this idea shows up
> from time to time), allowing splicing of results in function-call
> subexpressions would break equivalences that are currently exploited by
> macros and the compiler.
>
> For example, many macros assume that
>
>  (rator rand1 rand2 ... randn)
>
> can be rewritten as
>
>  (let ([r rator]
>        [a1 rand1]
>        [a2 rand2]
>        ...
>        [an randn])
>    (r a1 a2 ... an))
>
> That would not be the case if the `rand's can produce multiple values.
> (I assume that you don't want to allow binding multiple values to a
> variable in `let'.) I think that disallowing this kind of
> transformation would make many macros more difficult to implement ---
> and maybe impossible, in some cases.
>
> The Racket compiler takes advantage of transformations like the one
> above to speed up your code. Although the compiler could still perform
> transformations when the relevant subexpressions are known to be
> single-valued, I think the transformations would apply much less often
> than now.
>
> Along similar lines, various tools can tell statically you that
>
>  (cons e1 e2 e3)
>
> will be an arity error (assuming that `cons' is the usual binding).
> That kind of support would become much weaker, since `e2' might return
> zero values while `e1' and `e3' return a single value.
>
> In short, the kind of splicing that you suggest is a significant sense
> more "dynamic" than Racket. You could always embed such a dynamic
> language in Racket. Due to macros, however, I don't think it would work
> to re-interpret our existing code as being written in that language.
> And due to the extra constraints on the compiler and run-time system,
> I'm certain that it would perform worse than Racket. Overall, my sense
> is that the potential extra convenience of splicing values is not worth
> the costs.
>
> At Thu, 11 Jul 2013 10:42:52 -0400, Matthias Felleisen wrote:
> >
> > Your uses of values are covered in apply/map/append/list trickeries.
> Using
> > values might be more elegant, but yes, it's currently not possible.
> >
> >
> >
> > On Jul 11, 2013, at 8:56 AM, Laurent wrote:
> >
> > > In some postfix languages, if a procedure returns multiple values,
> these
> > values can be used directly as multiple arguments to another procedure
> call,
> > i.e., they are "spliced" in the latter call.
> > > In an extended Racket, this would look like this:
> > >
> > > (+ (values 1 2) (values 3 4))
> > > would be equivalent to
> > > (+ 1 2 3 4)
> > >
> > > (map values '(0 1 2) '(a b c))
> > > would return
> > > '(0 a 1 b 2 c)
> > >
> > > (call-with-values (lambda()(my-proc ....)) list)
> > > would simply be
> > > (list (my-proc ....))
> > >
> > > (values (values 1 2) (values 'a 'b))
> > > would be equivalent to
> > > (values 1 2 'a 'b)
> > >
> > > Correct me if I'm wrong, but I think all the cases where this feature
> should
> > be useful currently throws an error, so it would probably break only very
> > little.
> > >
> > > Such a missing feature tickles me from time to time, and I often find
> that
> > Racket `values' system is too cumbersome to be used more often, i.e.,
> you need
> > to go through stages of `call-with-values', 'let/define-values', `(apply
> values
> > ....)', etc. and I often find myself not wanting to go down this road.
> > >
> > > IMO, `values' is *meant* to be the way I describe above: `values' is
> exactly
> > like `list', except than instead of encapsulating the values in a
> container, it
> > splices them in-place.
> > >
> > > Do you see some disadvantages of using values this way?
> > > For example, in some occasions, for things like
> > > (define (foo x) (values x x))
> > > (map + (foo '(1 2 3)))
> > > it may be more difficult to infer that there are actually 2 lists in
> the map,
> > but to me it's just a matter of style/taste/comments/documentation, not a
> > matter of feature.
> > >
> > > Laurent
> > > ____________________
> > >  Racket Users list:
> > >  http://lists.racket-lang.org/users
> >
> >
> >
> ------------------------------------------------------------------------------
> > [application/pkcs7-signature "smime.p7s"] [~/Desktop & open] [~/Temp &
> open]
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130711/1ebadc50/attachment.html>