On Thu, Jul 11, 2013 at 09:18:30AM -0600, Matthew Flatt 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.
All this might be possible in typed racket, if the specific type(s) of a multiple returned value were known. > > In short, the kind of splicing that you suggest is a significant sense > more "dynamic" than Racket. And suitable typing would make it less dynamic again. -- hendrik ____________________ Racket Users list: http://lists.racket-lang.org/users
