I am deeply impressed. Python's Guido van Rossum is often suspected of owning a time machine, but apparently you have one too...
2013/7/11 Jay McCarthy <jay.mccar...@gmail.com> > On Thu, Jul 11, 2013 at 1:52 PM, Stephan Houben <stephan...@gmail.com> > 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. > > That's old news: > > https://github.com/jeapostrophe/exp/blob/master/values.ss > > FWIW, keywords aren't built-in in Racket for function calls, so this > approach to them in function returns *is* symmetric. > > Jay > > > Stephan Houben > > > > Op 11 jul. 2013 21:39 schreef "Jay McCarthy" <jay.mccar...@gmail.com> > 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 <laurent.ors...@gmail.com> > >> 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 <mfl...@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 > >> > > >> > > >> > > >> > ____________________ > >> > Racket Users list: > >> > http://lists.racket-lang.org/users > >> > > >> > >> > >> > >> -- > >> Jay McCarthy <j...@cs.byu.edu> > >> Assistant Professor / Brigham Young University > >> http://faculty.cs.byu.edu/~jay > >> > >> "The glory of God is Intelligence" - D&C 93 > >> ____________________ > >> Racket Users list: > >> http://lists.racket-lang.org/users > > > > -- > Jay McCarthy <j...@cs.byu.edu> > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 >
____________________ Racket Users list: http://lists.racket-lang.org/users
