[racket] Splicing `values' in-place

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.orseau at 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 <mflatt at 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 <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93