[racket] Splicing `values' in-place

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
Op 11 jul. 2013 21:39 schreef "Jay McCarthy" <jay.mccarthy at 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.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
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130711/3e1b4c87/attachment.html>