<div dir="ltr"><div><div>I am deeply impressed. </div>Python's Guido van Rossum is often suspected of owning a time machine, </div>but apparently you have one too... </div><div class="gmail_extra"> <div class="gmail_quote">2013/7/11 Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Thu, Jul 11, 2013 at 1:52 PM, Stephan Houben <<a href="mailto:stephanh42@gmail.com">stephanh42@gmail.com</a>> wrote: > Hi Jay, > > So what about keyword return values? > Both because of symmetry and because getting three return values straight is > just as hard as getting three arguments straight. </div>That's old news: <a href="https://github.com/jeapostrophe/exp/blob/master/values.ss" target="_blank">https://github.com/jeapostrophe/exp/blob/master/values.ss</a> FWIW, keywords aren't built-in in Racket for function calls, so this approach to them in function returns *is* symmetric. Jay <div class="HOEnZb"><div class="h5"> > Stephan Houben > > Op 11 jul. 2013 21:39 schreef "Jay McCarthy" <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> het > volgende: > >> I prefer to think of values as being justified by not restricting the >> arity of continuations. >> >> (let/cc k >> (k 1 2 3)) >> >> (let/cc k >> (k)) >> >> etc. >> >> define-values & let-values create N-arity continuations whereas >> call-with-values creates an any arity context >> >> Jay >> >> >> On Thu, Jul 11, 2013 at 12:23 PM, Laurent <<a href="mailto:laurent.orseau@gmail.com">laurent.orseau@gmail.com</a>> >> 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. >> > 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 <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> >> > 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: >> >> > > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >> >> > >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ >> >> > [application/pkcs7-signature "smime.p7s"] [~/Desktop & open] [~/Temp >> >> > & >> >> > open] >> >> > ____________________ >> >> > Racket Users list: >> >> > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >> > >> > >> > >> > ____________________ >> > Racket Users list: >> > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >> > >> >> >> >> -- >> Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>> >> Assistant Professor / Brigham Young University >> <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a> >> >> "The glory of God is Intelligence" - D&C 93 >> ____________________ >> Racket Users list: >> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> -- Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>> Assistant Professor / Brigham Young University <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a> "The glory of God is Intelligence" - D&C 93 </div></div></blockquote></div> </div>