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
____________________
Racket Users list:
http://lists.racket-lang.org/users
