<div dir="ltr"><div><div><div><div><div>Ah that unfortunately explains a lot. Thank you Matthew for this explanation.<br></div><div>It's too bad that one needs to throw away nice semantics for speed...<br></div><div><br> </div>Neil's macro idea may then well be one of the best intermediate solutions then.<br><br></div><div>Jens, thanks for all the links, they are quite informative.<br></div><div>Indeed, quite a number of people seem unhappy with `values'.<br> </div><div><br></div>However, since I did not find an answer for the following, I will risk this anyway: <br>Then why not return lists instead of values? Performance problem again?<br></div><div>There would not be such a thing as "multiple return values" though, and one should not see them this way.<br> </div><div>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.<br>No need for `apply-values' or `call-with-values', just use `apply'.<br> 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.<br></div><div>The type of the procedure would tell what is returned anyway.<br> </div>Some languages like Python, PHP (and Matlab?) do that, and I find this more convenient than `values'.<br></div></div><div><div>A "problem" would then be quieter errors for multiple/single value mismatch, but I don't really see this one as important.<br> </div><div>I also don't see the need for a different data type like `sequences' as they call it in Jen's thread.<br><br></div><div>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.<br> The above would make this much easier and simpler I suspect.<br></div><div><br>Laurent<br></div><div><br><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 5:18 PM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To elaborate on "currently not possible" (because this idea shows up<br> from time to time), allowing splicing of results in function-call<br> subexpressions would break equivalences that are currently exploited by<br> macros and the compiler.<br> <br> For example, many macros assume that<br> <br> (rator rand1 rand2 ... randn)<br> <br> can be rewritten as<br> <br> (let ([r rator]<br> [a1 rand1]<br> [a2 rand2]<br> ...<br> [an randn])<br> (r a1 a2 ... an))<br> <br> That would not be the case if the `rand's can produce multiple values.<br> (I assume that you don't want to allow binding multiple values to a<br> variable in `let'.) I think that disallowing this kind of<br> transformation would make many macros more difficult to implement ---<br> and maybe impossible, in some cases.<br> <br> The Racket compiler takes advantage of transformations like the one<br> above to speed up your code. Although the compiler could still perform<br> transformations when the relevant subexpressions are known to be<br> single-valued, I think the transformations would apply much less often<br> than now.<br> <br> Along similar lines, various tools can tell statically you that<br> <br> (cons e1 e2 e3)<br> <br> will be an arity error (assuming that `cons' is the usual binding).<br> That kind of support would become much weaker, since `e2' might return<br> zero values while `e1' and `e3' return a single value.<br> <br> In short, the kind of splicing that you suggest is a significant sense<br> more "dynamic" than Racket. You could always embed such a dynamic<br> language in Racket. Due to macros, however, I don't think it would work<br> to re-interpret our existing code as being written in that language.<br> And due to the extra constraints on the compiler and run-time system,<br> I'm certain that it would perform worse than Racket. Overall, my sense<br> is that the potential extra convenience of splicing values is not worth<br> the costs.<br> <div><div class="h5"><br> At Thu, 11 Jul 2013 10:42:52 -0400, Matthias Felleisen wrote:<br> ><br> > Your uses of values are covered in apply/map/append/list trickeries. Using<br> > values might be more elegant, but yes, it's currently not possible.<br> ><br> ><br> ><br> > On Jul 11, 2013, at 8:56 AM, Laurent wrote:<br> ><br> > > In some postfix languages, if a procedure returns multiple values, these<br> > values can be used directly as multiple arguments to another procedure call,<br> > i.e., they are "spliced" in the latter call.<br> > > In an extended Racket, this would look like this:<br> > ><br> > > (+ (values 1 2) (values 3 4))<br> > > would be equivalent to<br> > > (+ 1 2 3 4)<br> > ><br> > > (map values '(0 1 2) '(a b c))<br> > > would return<br> > > '(0 a 1 b 2 c)<br> > ><br> > > (call-with-values (lambda()(my-proc ....)) list)<br> > > would simply be<br> > > (list (my-proc ....))<br> > ><br> > > (values (values 1 2) (values 'a 'b))<br> > > would be equivalent to<br> > > (values 1 2 'a 'b)<br> > ><br> > > Correct me if I'm wrong, but I think all the cases where this feature should<br> > be useful currently throws an error, so it would probably break only very<br> > little.<br> > ><br> > > Such a missing feature tickles me from time to time, and I often find that<br> > Racket `values' system is too cumbersome to be used more often, i.e., you need<br> > to go through stages of `call-with-values', 'let/define-values', `(apply values<br> > ....)', etc. and I often find myself not wanting to go down this road.<br> > ><br> > > IMO, `values' is *meant* to be the way I describe above: `values' is exactly<br> > like `list', except than instead of encapsulating the values in a container, it<br> > splices them in-place.<br> > ><br> > > Do you see some disadvantages of using values this way?<br> > > For example, in some occasions, for things like<br> > > (define (foo x) (values x x))<br> > > (map + (foo '(1 2 3)))<br> > > it may be more difficult to infer that there are actually 2 lists in the map,<br> > but to me it's just a matter of style/taste/comments/documentation, not a<br> > matter of feature.<br> > ><br> > > Laurent<br> > > ____________________<br> > > Racket Users list:<br> > > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br> ><br> ><br> </div></div>> ------------------------------------------------------------------------------<br> > [application/pkcs7-signature "smime.p7s"] [~/Desktop & open] [~/Temp & open]<br> <div class="HOEnZb"><div class="h5">> ____________________<br> > Racket Users list:<br> > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br> </div></div></blockquote></div><br></div>