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. Stephan Houben <div class="gmail_quote">Op 11 jul. 2013 21:39 schreef "Jay McCarthy" <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> het volgende: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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> </blockquote></div>