[racket] Splicing `values' in-place

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.mccarthy at gmail.com>

> On Thu, Jul 11, 2013 at 1:52 PM, Stephan Houben <stephanh42 at 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.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
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130712/9b5cb79d/attachment-0001.html>