The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Motivations for multiple return values feature?
 There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic. There was an error processing your request. Please try again. Standard view   View as tree
 Messages 26 - 50 of 163 < Older  Newer >

From:
To:
Cc:
Followup To:
Subject:
 Validation: For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon.

More options Apr 9 2002, 9:59 pm
Newsgroups: comp.lang.scheme
From: o...@pobox.com (o...@pobox.com)
Date: 9 Apr 2002 18:59:50 -0700
Local: Tues, Apr 9 2002 9:59 pm
Subject: Re: Motivations for multiple return values feature?
No doubt multiple return values are highly useful, especially in
writing pure functional code.

However, multiple-values give rise to some difficulties. For example,
the functional identity can no longer be defined as
(define (id x) x)
if we want it to be the unit of the functional composition. Instead,
we have to
(define (id . args) (apply values args))
The functional composition becomes more complex, too.

Oftentimes we wish for a function (trace "some-string" val) that
merely propagates the "val" to its caller. The utility of such a
function is in its side-effect, e.g., printing a message:

(define (trace title arg)
(display title) (newline)
; perhaps print the timestamp as well
arg)  ; propagate the arg

The function can be used as
(trace "got request" (get-request)))

This pattern of propagating a value is quite widespread: it occurs in
procedures such as "call-with-input-file" (which must close the port
before passing the value returned by its body) and forms such as
dynamic-wind. The presence of multiple values noticeably complicates
the definitions of such procedures:

(define (trace title . args)
(display title) (newline)
(apply values args))

(call-with-values
get-request
(lambda args
(call-with-values
(lambda () (apply trace (cons title args)))

It is interesting to note that in these situations we often have to
specifically reify multiple values as a list.

The function 'values' itself is more complex than it seems. [in the
following, we mean the function values applied to more or fewer than 1
argument] Perhaps 'values' the only R5RS function that does not yield a
value. The "result" of 'values' is not first-class. BTW, R5RS
specifically says that an "unspecified" result is still a first-class
value. The only other function whose result is not first-class is
'error' (or 'abort', following SRFI-12).

The similarity between 'values' and 'error' runs deeper. One can say
that neither of these functions actually return. That is, they do not
invoke their 'natural' continuation. The function error invokes the
error continuation, which is always present (often implicitly). The
function 'values' invokes a multiple-value continuation, which must be
established by a distinguished 'call-with-values' procedure. The
implementation of 'values' in R5RS corroborates this interpretation.
We can imagine 'values' throwing a special kind of exception, which is
trapped in the handler set by 'call-with-values'. The multiple-values
"exception" is a peculiar one: it can't percolate so it must be caught
right away.

To post a message you must first join this group.
You do not have the permission required to post.
More options Apr 9 2002, 10:45 pm
Newsgroups: comp.lang.scheme
From: "Joe Marshall" <prunesqual...@attbi.com>
Date: Wed, 10 Apr 2002 02:40:06 GMT
Local: Tues, Apr 9 2002 10:40 pm
Subject: Re: Motivations for multiple return values feature?

"Bruce Hoult" <br...@hoult.org> wrote in message

news:bruce-7C2967.12554310042002@copper.ipg.tsnz.net...

Looks more like syntactic curry' to me.

To post a message you must first join this group.
You do not have the permission required to post.
More options Apr 9 2002, 10:51 pm
Newsgroups: comp.lang.scheme
From: Eli Barzilay <e...@barzilay.org>
Date: 09 Apr 2002 22:51:06 -0400
Local: Tues, Apr 9 2002 10:51 pm
Subject: Re: Motivations for multiple return values feature?

Matthias Blume <matth...@shimizu-blume.com> writes:
> [...]  Personally, I have come to prefer languages that lets in
> neither, i.e., strict single-argument single-result functions, with
> a first-class tupling mechanisms that give you the expressive power
> of multiple arguments/results.  Static analysis (e.g., type
> checking) can often effectively be used to eliminate the overhead of
> creating actual tuples.

I don't want to sound like this is c.l.l, but it looks like this
carries zero information -- people who haven't tried it probably don't
know what you're talking about here, and people who do must have some
good reason to use Scheme.

(Personally, I have *really* tried working with ML, but I have come to
realize that no matter how hard I try to do that, a dynamic language
is always more fun to use.)

--
((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
http://www.barzilay.org/                 Maze is Life!

To post a message you must first join this group.
You do not have the permission required to post.
More options Apr 9 2002, 10:56 pm
Newsgroups: comp.lang.scheme
From: Bruce Hoult <br...@hoult.org>
Date: Wed, 10 Apr 2002 14:56:19 +1200
Local: Tues, Apr 9 2002 10:56 pm
Subject: Re: Motivations for multiple return values feature?
In article <aCNs8.17635$%s3.5944...@typhoon.ne.ipsvc.net>, "Joe Marshall" <prunesqual...@attbi.com> wrote: Curry contains sugar. And a little spice... -- Bruce You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 3:19 am Newsgroups: comp.lang.scheme From: "Sébastien de Menten" <sdementen_at_hotmail.com> Date: Wed, 10 Apr 2002 09:17:57 +0200 Local: Wed, Apr 10 2002 3:17 am Subject: Re: Motivations for multiple return values feature? > This criterion of elegance can be pushed even farther -- why bother > distinguishing arguments from return values? Mathematically, a function > is just a special case of a relation, and in the realm of programming > languages this perspective is taken by Prolog. Loosely speaking, a function f is a relation between elements of two different sets (domain(f) and image(f)) with the particularity that each element of the first set (x in domain(f)) is related to only_one element of the other set ( f(x) in image(f)). > But the tradition of functions as things with multiple arguments and > one return value is about 1000 years older than this more abstract > definition (and even more older than the one-argument-function lambda > calculus), and it clearly (imho) captures something really useful > and rich, even today. Multiple-return-value functions don't feel like > functions to me. Multiple return value is still a function but with a composed set image(f). For instance, f = (lambda (x1 x2 x3) (values (* 2 x1) (/ x2 x3)) is just a function with : - domain(f) = SCM^3 - image(f)=SCM^2 with SCM being the set of scheme values. But for each input in domain(f), it returns one output in image(f). Hence, - if f returns a single composed value for each input => f is a function (the case with the "Multiple-return-value functions") - if f returns a list of values (being composed or not) => f is not a function but a more general relation (f doesn't feel like a function because it isn't). In this case, the returned list can be of different size at each call. This may not be useful at first sight but is heavely used in relational databases. Anyway, I find the multiplevalue stuff mathematically nice but its syntax is ugly. What would be nice is to be able to write: (define (f x y z) ... (values v w)) (define (g x y) ... (values s)) with (g (f 3 4 5)) or (g 4 6) being to possible calls You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 5:25 am Newsgroups: comp.lang.scheme From: MJ Ray <markj+0...@cloaked.freeserve.co.uk> Date: Tue, 09 Apr 2002 23:59:22 GMT Local: Tues, Apr 9 2002 7:59 pm Subject: Re: Motivations for multiple return values feature? Dorai Sitaram <d...@goldshoe.gte.com> wrote: > There is already the procedure apply that can do the > unpacking without let, car, cdr, list-ref, etc. I always seem to take a performance hit when using apply. Has anyone got benchmarks of the two ways round? You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 5:25 am Newsgroups: comp.lang.scheme From: MJ Ray <markj+0...@cloaked.freeserve.co.uk> Date: Tue, 09 Apr 2002 23:57:17 GMT Local: Tues, Apr 9 2002 7:57 pm Subject: Re: Motivations for multiple return values feature? George Caswell <sieg_h...@attbi.com> wrote: > I did explain my current (limited) understanding of multiple return > values. About the only reason I could fathom for its existence was in > order to make the representation match the intent. I humbly suggest that, > in order to make your responses useful, you pay attention to what you're > reading. I did not understand your attempted explanation (which looks to me like part of a sentence), so I did not try to answer that part. Now that I see you seem to enjoy abusing those whose replies do not meet your exacting completeness standards, I regret following up at all. I will try not to make that error again and humbly apologise for offending you. You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 6:24 am Newsgroups: comp.lang.scheme From: "felix" <felixundd...@freenet.de> Date: Wed, 10 Apr 2002 11:53:10 +0200 Local: Wed, Apr 10 2002 5:53 am Subject: Re: Motivations for multiple return values feature? MJ Ray wrote in message ... >Dorai Sitaram <d...@goldshoe.gte.com> wrote: >> There is already the procedure apply that can do the >> unpacking without let, car, cdr, list-ref, etc. >I always seem to take a performance hit when using apply. Has anyone got >benchmarks of the two ways round? There is a paper by Kent Dybvig ("Efficient Implementation of Multiple Return Values in Scheme" (or so)), which compares the performance of different programming styles (values, CPS, lists, etc.). Should be available at readscheme.org. Brad Lucier reported timings for a benchmark of the SRFI-25 reference implementation where native multiple values[*] showed to be about 5 times faster than multiple values simulated with lists/apply cheers, felix -- [*] with a preliminary release of Gambit (4.0) You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 6:24 am Newsgroups: comp.lang.scheme From: "felix" <felixundd...@freenet.de> Date: Wed, 10 Apr 2002 11:59:00 +0200 Subject: Re: Motivations for multiple return values feature? Jeffrey Siegal wrote in message <3CB363BC.241B3...@quiotix.com>... >Barry Margolin wrote: >> As others have mentioned, it allows for some runtime optimization. >I wouldn't say it "allows" optimization, since optimization is always >allowed. It might make optmization somewhat easier, but even that seems >questionable. I do not understand. Do you mean optimizing for multiple values is not automatically easier than optimizing for a list-hack? I don't think so (see Dybvig's paper). cheers, felix You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 6:24 am Newsgroups: comp.lang.scheme From: "felix" <felixundd...@freenet.de> Date: Wed, 10 Apr 2002 12:08:56 +0200 Local: Wed, Apr 10 2002 6:08 am Subject: Re: Motivations for multiple return values feature? Since call-with-values is just a building-block, one can just as well say: (let-values ([(v1 v2 v3) (function-returning-3values params)]) (function-to-process v1 v2) (another-function v3) ) Less noise, looks better, makes the intention clear, doesn't need a magic compiler and is efficient (by using the native call-with-values). cheers, felix You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 7:31 am Newsgroups: comp.lang.scheme From: Matthias Blume <matth...@shimizu-blume.com> Date: 10 Apr 2002 07:29:36 -0400 Local: Wed, Apr 10 2002 7:29 am Subject: Re: Motivations for multiple return values feature? Well, that just makes the point very clearly: multiple values are a *performance* hack. -- -Matthias You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 7:51 am Newsgroups: comp.lang.scheme From: Matthias Blume <matth...@shimizu-blume.com> Date: 10 Apr 2002 07:35:01 -0400 Local: Wed, Apr 10 2002 7:35 am Subject: Re: Motivations for multiple return values feature? Eli Barzilay <e...@barzilay.org> writes: > Matthias Blume <matth...@shimizu-blume.com> writes: > > [...] Personally, I have come to prefer languages that lets in > > neither, i.e., strict single-argument single-result functions, with > > a first-class tupling mechanisms that give you the expressive power > > of multiple arguments/results. Static analysis (e.g., type > > checking) can often effectively be used to eliminate the overhead of > > creating actual tuples. > I don't want to sound like this is c.l.l, but it looks like this > carries zero information -- people who haven't tried it probably don't > know what you're talking about here, and people who do must have some > good reason to use Scheme. I'd prefer it if you'd speak for yourself only. I am pretty sure that there are people who do know what I am talking about. The above isn't that difficult to understand. (If you think that I simply made a thinly-veiled reference to ML and want the above to be read "I prefer ML", then you are wrong. I intentionally did not mention the concrete instance ML of the broader class of languages that I would prefer as far as their handling of arguments and return values of functions is concerned.) > (Personally, I have *really* tried working with ML, but I have come to > realize that no matter how hard I try to do that, a dynamic language > is always more fun to use.) Well, different strokes for different folks. Anyway, this was not at all about static vs. dynamic, so I don't quite see why you need to bring it up. -- -Matthias You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 9:52 am Newsgroups: comp.lang.scheme From: Eli Barzilay <e...@barzilay.org> Date: 10 Apr 2002 09:52:14 -0400 Local: Wed, Apr 10 2002 9:52 am Subject: Re: Motivations for multiple return values feature? Matthias Blume <matth...@shimizu-blume.com> writes: > > > [...] Personally, I have come to prefer languages that lets in > > > neither, i.e., strict single-argument single-result functions, > > > with a first-class tupling mechanisms that give you the > > > expressive power of multiple arguments/results. Static analysis > > > (e.g., type checking) can often effectively be used to eliminate > > > the overhead of creating actual tuples. > I'd prefer it if you'd speak for yourself only. You did not even mention pattern matching to destruct the touple. (And my guess was that anyone who'll know how static analysis can prevent creating these touples belongs to that crowd that knows this already.) > (If you think that I simply made a thinly-veiled reference to ML and > want the above to be read "I prefer ML", then you are wrong. Substitute ML' with languages that have only strict single-argument single-result functions' and that use Static analysis to eliminate overhead'. The ML reference was my theoretical mistake that came out of the practical reality where you posted something about ML in the same neighborhood. But all this is pointless meta-junk, the only thing I wanted to say is exactly this: > Well, different strokes for different folks. ... so what's the point of tempting people to reduce the S/N ratio? > Anyway, this was not at all about static vs. dynamic, so I don't > quite see why you need to bring it up. (Yeah well, the standard approach would be to say that: if multiple return values are a hack, but without them you have a non-symmetrical situation that pushes you to forbid multiple inputs, leading to unbearable Scheme overhead for almost every function call, which can be fixed by using static type analysis and pattern matching, then my reply is that giving up dynamisms that will follow is a way too high price. etc etc etc.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 11:04 am Newsgroups: comp.lang.scheme From: Matthias Blume <matth...@shimizu-blume.com> Date: 10 Apr 2002 10:58:43 -0400 Local: Wed, Apr 10 2002 10:58 am Subject: Re: Motivations for multiple return values feature? Strictly speaking, you don't need any pattern matching. In this case it would just be syntactic sugar. For conciseness of notation, it would definitely help, though. > > (If you think that I simply made a thinly-veiled reference to ML and > > want the above to be read "I prefer ML", then you are wrong. > Substitute ML' with languages that have only strict single-argument > single-result functions' and that use Static analysis to eliminate > overhead'. Such languages have a bit of an easier time with first-class multiple values because they *already* do type analysis for other reasons and therefore can piggy-back on that. But the analysis used in, e.g., Scheme, does not have to be a type analysis in the usual sense. Instead, it could be some fairly straightforward CFA, or soft typing, etc. (Actually, those really all boil down to the same thing: CFA.) > > Well, different strokes for different folks. > ... so what's the point of tempting people to reduce the S/N ratio? The point is that call-with-values and values are "features piled on top of features" -- something that does not give you any additional expressive power, in fact, something that is strictly less expressive than *another* language feature that is *already* in the language. The only thing it has going for itself is the fact that naive implementations can optimize it a bit more easily -- hence the word "performance hack". As I have showed in a previous article, there are situations where the hack actually amounts to a pessimisation. In terms of pragmatics, it is definitely a pessimisation because I need to contort all kinds of otherwise clean code to account for the possibility of multiple values. I do not understand why you think that discussing this is reducing the S/N ratio. CWV and VALUES go very much against the spirit of the design principles that Scheme is so proud of. > > Anyway, this was not at all about static vs. dynamic, so I don't > > quite see why you need to bring it up. > (Yeah well, the standard approach would be to say that: if multiple > return values are a hack, but without them you have a non-symmetrical > situation that pushes you to forbid multiple inputs, leading to > unbearable Scheme overhead for almost every function call, which can > be fixed by using static type analysis and pattern matching, It can be fixed by a clever compiler, doing *some* kind of compile time analysis. Compilers (even -- or should I say, *especially* those for Scheme) do all kinds of other clever static analyses, too. Static typing at the level of the surface language is not required for this (although it helps if you already have it). Pattern matching has absolutely *nothing* to do with performance one way or the other here. By the way, the "unbearable" overhead does not have to be all that "unbearable" even in an implementation that does not do any sophisticated static analysis: Suppose we have the following semantics of abstraction and application: 1. Abstraction: (LAMBDA (x) <body>) -- takes the function's single argument, binds it to X and evaluates <body> (LAMBDA () <body>) -- takes the function's single argument which must (dynamically) be of type "tuple" with zero components (aka "unit"). Evaluate <body>. (LAMBDA (x1 ... xN) <body>) -- takes the function's single argument which must be of type "tuple" with N components. Bind component i to xi for all i \in 1 .. N. Evaluate <body>. If we assume that there is a form expressing projection for tuples, say (project <tuple> <i>) gives you the <i>th component of <tuple>, then the second form is syntactic sugar for (LAMBDA (arg) <check type of arg to be 0-tuple> <body>) and the last form is syntactic sugar for (LAMBDA (arg) <check type of arg to be N-tuple> (let ((x1 (project arg 1)) ... (xN (project arg N))) <body>)) Notice that techinally all LAMBDA forms evaluate to procedures taking a single argument. 2. Application: (<function> <arg>) -- evaluates <function> and <arg>, <function> must be a procedure, <arg> can be anything. Call <function> with <arg> as its single argument. (<function>) -- evaluates <function>, result must be a procedure expecting a "unit" (see above) argument. Call it with a unit value (empty tuple) as its single argument. (<function> <arg1> ... <argN>) -- evaluates <function> and all <argi>. <function> must be a procedure taking an N-tuple, bundle up <argi> as such an N-tuple, pass it to the procedure as its single argument. If we assume that there is a form expressing tupling, say (tuple <x1> ... <xN>) for N >= 0, then the second form is syntactic sugar for (<function> (tuple)) and the last form is syntactic sugar for (<function> (tuple <arg1> ... <argN>)) If we further assume that (tuple <x>) simply returns <x>, then all three forms can be seens as instances of the same kind of syntactic sugaring. Obviously, the first two forms of application are as cheap (or very nearly so) as those in any existing Scheme implementation. The potential performance hit comes with the third form. So here is what we do: Instead of creating the tuple in the caller, we pass the values <arg1> ... <argN> in "unpacked" form (e.g., as individual stack slots, or even in registers), just like it is done currently in Scheme. In addition, as any prudent Scheme implementation must do, we also say how big N actually is. (Current Scheme implementations must do the latter, too, in order to be able to detect arity mismatches dynamically.) Now, on the callee side, we proceed as follows: In the (LAMBDA (x) <body>) case, we check to see if N = 1. If so, we simply take the value, bind it to x, and continue with <body> In the case of N = 0, we bind x to an empty tuple and evaluate <body>. In the case of N > 0, we now tuple up the arguments, bind the resulting tuple to x, and then continue. Notice that the only expensive case here is the one that would be considered a dynamic type error in existing Schemes. In the (LAMBDA () <body>) case, we check to see if N = 0. If so, we proceed with <body>. In all other cases we raise an error. In the (LAMBDA (x1 ... xM) <body>) case, we check to see if: M = N => bind x1 ... xN as usual and proceed with <body> N = 1 => check the type of the actual argument. It must be a tuple of size M. If so, unpack the tuple, bind x1 ... xM, and proceed. If not, raise an error. otherwise => raise error Again, the only expensive case occurs where traditional Schemes would raise an error anyway. The point of all this is that from the point of the semantics of the surface language, multiple values (for both arguments and results) are good old-fashioned first-class values like everything else in Scheme. And to get good performance on the critical path case where first-class-ness is not semantically required, we do the actual tupling lazily, using more efficient parameter-passing mechanisms wherever possible. In other words, there really is no excuse for having CALL-WITH-VALUES and VALUES in a language. > then my reply is that giving up dynamisms that will follow is a way > too high price. etc etc etc.) Calm down. Nobody asked you to give up your precious dynamisms. :-) -Matthias You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 11:08 am Newsgroups: comp.lang.scheme From: George Caswell <sieg_h...@attbi.com> Date: Wed, 10 Apr 2002 15:04:34 GMT Local: Wed, Apr 10 2002 11:04 am Subject: Re: Motivations for multiple return values feature? On Tue, 9 Apr 2002, MJ Ray wrote: > George Caswell <sieg_h...@attbi.com> wrote: > > I did explain my current (limited) understanding of multiple return > > values. About the only reason I could fathom for its existence was in > > order to make the representation match the intent. I humbly suggest that, > > in order to make your responses useful, you pay attention to what you're > > reading. > I did not understand your attempted explanation (which looks to me like part > of a sentence), so I did not try to answer that part. Now that I see you > seem to enjoy abusing those whose replies do not meet your exacting > completeness standards, I regret following up at all. I will try not to > make that error again and humbly apologise for offending you. Apology accepted. More seriously: This is just an ongoing pet peeve of mine - someone asks for a question to be answered, and the answer is of the form of "why would you do that?" or "why are you asking that question?" Something pretty much orthogonal to the question being asked. Answers like this are noise. In this case I asked why (values) exists. Your first answer was along the lines of "You can turn values into a list", and IMO did not at all address the question. Your second answer was that you felt it was more semantically clean than using lists. The second answer did address the question, and I appreciate the input. Anyway, thanks to everybody who helped me out with this. ---GEC New projects page: http://home.attbi.com/~sieg_haro/ (M-x depeche-mode) "Must... Finish... Zaku..." You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 11:20 am Newsgroups: comp.lang.scheme From: Matthias Blume <matth...@shimizu-blume.com> Date: 10 Apr 2002 11:04:21 -0400 Local: Wed, Apr 10 2002 11:04 am Subject: Re: Motivations for multiple return values feature? Matthias Blume <matth...@shimizu-blume.com> writes: > In the (LAMBDA () <body>) case, we check to see if N = 0. If so, > we proceed with <body>. In all other cases we raise an error. Sorry, got this one wrong. Should have said: In the (LAMBDA () <body>) case, we check to see if N = 0. If so, we proceed with <body>. If N = 1, we check the type of the single argument, which must be "unit". If so, we proceed with <body>. Otherwise, we raise an error. If N > 1, we raise an error. -- -Matthias You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 11:57 am Newsgroups: comp.lang.scheme From: Eli Barzilay <e...@barzilay.org> Date: 10 Apr 2002 11:57:19 -0400 Local: Wed, Apr 10 2002 11:57 am Subject: Re: Motivations for multiple return values feature? Matthias Blume <matth...@shimizu-blume.com> writes: > The point is that call-with-values and values are "features piled on > top of features" -- something that does not give you any additional > expressive power, in fact, something that is strictly less > expressive than *another* language feature that is *already* in the > language. [...] > In terms of pragmatics, it is definitely a pessimisation because I > need to contort all kinds of otherwise clean code to account for the > possibility of multiple values. At this point I have to admit that I am pretty much leaning towards this opinion. The only thing that I found useful with multiple values is in case you want to define several functions sharing a single (hidden) state without using a redundant binding as in (define f+g (let ((state ...)) (let ((f ...) (g ...)) (list f g)))) (define f (car f+g)) (define g (cadr f+g)) but this needs some form of define-values'. > I do not understand why you think that discussing this is reducing > the S/N ratio. [...] Well discussing *this* is certainly bringing it up -- it's those "I can do X if I had feature Y in my language", for any property Y that is far enough from Scheme to be impractical or even something to learn from. So your current post is definitely good stuff, compared to the other. (You probably think that this one is just being more verbose...) > Suppose we have the following semantics of abstraction and application: > 1. Abstraction: > [...] > 2. Application: > [...] > If we further assume that (tuple <x>) simply returns <x>, then > all three forms can be seens as instances of the same kind of > syntactic sugaring. > [...] So here is what we do: Instead of creating the tuple in the > caller, we pass the values <arg1> ... <argN> in "unpacked" form > (e.g., as individual stack slots, or even in registers), just like > it is done currently in Scheme. In addition, as any prudent Scheme > implementation must do, we also say how big N actually is. (Current > Scheme implementations must do the latter, too, in order to be able > to detect arity mismatches dynamically.) Yes (just need to make the above a bit more complex to allow variable number of arguments), but after you've done all this, you end up with something which looks exactly like the current state of things without multiple values, which you could add to reify these tuples. And maybe then add a form that will be a function application using a user-supplied tuple, as with CL's `multiple-value-call': (multiple-value-call f (values ...)) Do you see any practical result of your description which makes things different than where they are now? > Calm down. Nobody asked you to give up your precious dynamisms. :-) Whew... (Semi-seriously, I think it's good to worry about this, there's no doubt static languages have advantages, so I think it's good to have a reality check every once in a while... The easiness of expressing any argument structure in ML with minimized performance penalty is certainly one of these attractive features. (I even implemented a pattern matcher as a result.)) Disclaimer: it is getting very late for me (in contrast to the local timezone), so I apologize in advance if there's anything obviously stupid in the above... Time to crash now... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 12:00 pm Newsgroups: comp.lang.scheme From: ozan s yigit <o...@blue.cs.yorku.ca> Date: 10 Apr 2002 11:59:06 -0400 Local: Wed, Apr 10 2002 11:59 am Subject: Re: Motivations for multiple return values feature? Matthias Blume <matth...@shimizu-blume.com> writes: > Well, that just makes the point very clearly: multiple values > are a *performance* hack. it is a *programmer* performance hack. oz -- you take a banana, you get a lunar landscape. -- j. van wijk You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 12:00 pm Newsgroups: comp.lang.scheme From: ozan s yigit <o...@blue.cs.yorku.ca> Date: 10 Apr 2002 11:45:26 -0400 Local: Wed, Apr 10 2002 11:45 am Subject: Re: Motivations for multiple return values feature? Barry Margolin <bar...@genuity.net> writes: > But in fact, we don't require programmers to package up multiple input > values that way. So why should we require them to do so for multiple > output values? this is the crux of it. it also makes it less clumsy, easier to understand less error-prone etc etc. multiple return values are not a luxury. oz --- the power of the unaided human mind is highly overrated. -- Donald Norman You must Sign in before you can post messages. To post a message you must first join this group. Please update your nickname on the subscription settings page before posting. You do not have the permission required to post. More options Apr 10 2002, 12:04 pm Newsgroups: comp.lang.scheme From: Barry Margolin <bar...@genuity.net> Date: Wed, 10 Apr 2002 16:04:12 GMT Local: Wed, Apr 10 2002 12:04 pm Subject: Re: Motivations for multiple return values feature? In article <a8vpav$mk...@abbenay.CS.Berkeley.EDU>,

Brian Harvey <b...@abbenay.cs.berkeley.edu> wrote:
>But the tradition of functions as things with multiple arguments and
>one return value is about 1000 years older than this more abstract
>definition

Really?  Didn't many early programming languages, such as Algol, allow you
to specify IN, OUT, and IN-OUT parameters to procedures?  Multiple values
allows you to get an effect analogous to multiple OUT parameters.

It's true that when procedures are used as functions in expressions,
there's a distinguished return value, and it's traditionally been a
singleton (so that it can be substituted into the expression).  In some
languages a function can assign to its OUT parameters while also returning
a value, but the Lisp family doesn't support this.  So multiple return
values were introduced to fill the gap.  As I mentioned in another post,
Common Lisp recognizes the special status of the primary value when a
function call appears in an ordinary expression, by ignoring any extra
values.

--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

To post a message you must first join this group.
You do not have the permission required to post.
More options Apr 10 2002, 12:08 pm
Newsgroups: comp.lang.scheme
From: Marc Feeley <fee...@IRO.UMontreal.CA>
Date: Wed, 10 Apr 2002 16:08:10 GMT
Local: Wed, Apr 10 2002 12:08 pm
Subject: Re: Motivations for multiple return values feature?

> > Brad Lucier reported timings for a benchmark of the SRFI-25 reference
> > implementation where native multiple values[*] showed to be about 5 times
> > faster than multiple values simulated with lists/apply

> Well, that just makes the point very clearly: multiple values are a *performance* hack.

I should point out that the implementation of multiple values in
Gambit is really straightforward.  It simply consists in packaging the
values in a specially tagged vector (except when there is a single
value).  I think the factor of 5 performance improvement observed is
simply due to the inlining of the allocator.  So you could get the
same performance with (vector value1 value2 ...) if you use the right
declarations for this call to be inlined.

I don't like multiple values, but they are supported in Gambit 4.0
for compatibility with R5RS.

Marc

To post a message you must first join this group.
You do not have the permission required to post.
More options Apr 10 2002, 12:35 pm
Newsgroups: comp.lang.scheme
From: d...@goldshoe.gte.com (Dorai Sitaram)
Date: 10 Apr 2002 16:35:58 GMT
Local: Wed, Apr 10 2002 12:35 pm
Subject: Re: Motivations for multiple return values feature?
In article <vi4it6z8rzp....@blue.cs.yorku.ca>,
ozan s yigit  <o...@blue.cs.yorku.ca> wrote:

>Matthias Blume <matth...@shimizu-blume.com> writes:

>> Well, that just makes the point very clearly: multiple values
>> are a *performance* hack.

>it is a *programmer* performance hack.

OK, I guess you have some examples and want us to ask.

Give a couple of examples.

To post a message you must first join this group.
You do not have the permission required to post.
More options Apr 10 2002, 12:47 pm
Newsgroups: comp.lang.scheme
From: Matthias Blume <matth...@shimizu-blume.com>
Date: 10 Apr 2002 12:32:25 -0400
Local: Wed, Apr 10 2002 12:32 pm
Subject: Re: Motivations for multiple return values feature?

Eli Barzilay <e...@barzilay.org> writes:
> Do you see any practical result of your description which makes things
> different than where they are now?

Absolutely.  For starters, I can write "compose" the way I wanted it:

(define ((compose f g) x) (f (g x)))

This handles all cases, including g or f taking or produces multiple values.

Since multiple values are now first-class values, you can even do things like

(map f (map g <list>))

where g might return multiple values.  The intermediate list would
nicely collect them as first-class tuples and dispatch the
(potentially) multiple-arg f to work on those.  Imagine the
contortions that you'd need in current Schemes.

Let's try, assuming that multiple args for g are given as sublists
of <list>, and that multiple results of f are to be collected as
sublists of the final result:

(map (lambda (args)
(call-with-values (lambda () (apply f args)) list))
(map (lambda (args)
(call-with-values (lambda () (apply g args)) list))
<list>))

(Don't sue me if I didn't get this right.  It would only make my point
-- namely being awkward beyond reason.)

-Matthias

To post a message you must first join this group.
You do not have the permission required to post.
More options Apr 10 2002, 12:52 pm
Newsgroups: comp.lang.scheme
From: jengl...@flightlab.com (Joe English)
Date: 10 Apr 2002 16:27:42 GMT
Local: Wed, Apr 10 2002 12:27 pm
Subject: Re: Motivations for multiple return values feature?

Matthias Blume wrote:
>"felix" writes:
>> There is a paper by Kent Dybvig ("Efficient Implementation of Multiple
>> Return Values in Scheme" (or so)), which compares the performance
>> of different programming styles (values, CPS, lists, etc.). Should

>> Brad Lucier reported timings for a benchmark of the SRFI-25 reference
>> implementation where native multiple values[*] showed to be about 5 times
>> faster than multiple values simulated with lists/apply

>Well, that just makes the point very clearly: multiple values are a
>*performance* hack.

What's always puzzled me is that in Ashley & Dybvig's paper,
the only way they were able to actually get increased performance
is to transform things like

(call-with-values
(lambda () producer)
(lambda (v1 v2 ... vN) consumer))

into:

(mv-let producer (v1 v2 ... vN) consumer)

where mv-let (and mv-call) are implemented as primitives.
Performing this transformation is complicated by the fact
that call-with-values is an ordinary procedure, not syntax.

Further, the code I've seen written to demonstrate the utility
of multiple return values almost invariably defines macros to
provide Lisp-style (multiple-value-bind) and (multiple-value-call)
as syntactic sugar for (call-with-values).

I really wonder why R5RS specified (call-with-values) as the
essential primitive instead of (mv-let) and (mv-call), when
the former is too ugly to be used directly by programmers
and too awkward to be implemented efficiently without first
transforming it into the latter.  Was there a moratorium on
introducing new special forms in effect at the time, or what?

--Joe English

jengl...@flightlab.com

To post a message you must first join this group.
You do not have the permission required to post.
More options Apr 10 2002, 12:58 pm
Newsgroups: comp.lang.scheme
From: g...@jpl.nasa.gov (Erann Gat)
Date: Wed, 10 Apr 2002 08:21:15 -0800
Local: Wed, Apr 10 2002 12:21 pm
Subject: Re: Motivations for multiple return values feature?
In article <fo1ydnbnx8....@trex10.cs.bell-labs.com>, Matthias Blume

<matth...@shimizu-blume.com> wrote:
> Suppose we have the following semantics of abstraction and application:

>   1. Abstraction:

>      (LAMBDA (x) <body>)   -- takes the function's single argument, binds
>                               it to X and evaluates <body>

Did you mean (lambda x body)?  The design as you presented it changes the
semantics of Scheme, e.g.:  ((lambda (x) x) 1 2) in Scheme is an error but
in your semantics is (tuple 1 2).

Your proposed semantics also require a tuple of one element to be eq to
the element, which seems very weird to me.

E.