Hi,
I'm wondering why MULTIPLE-VALUE-BIND doesn't allow you to specify
default values. This change wouldn't even interfere with the current
definition. So, for example, if you wanted to do:
(multiple-value-bind (x (y 0)) (compute-1-or-maybe-2-values)
...)
I don't know how I'd treat this for the case where subsequent bindings
take on deafult values which depend on previous bindings, e.g.:
(multiple-value-bind* (x (y (1+ x))) (compute-1-or-maybe-2-values)
...)
I don't know if this feature would even be worth naming another macro
for, or if the current MULTIPLE-VALUE-BIND would just behave like the
2nd above. But default values for non-returned values would be useful
at times.
I would find such a feature to be moderately valuable, and since it
would not slow down the current implementation of MULTIPLE-VALUE-BIND
when the bindings are simple (since all the defaulting behavior is
known at compile-time), I think this is something I'd recommend
changing if that were possible.
Of course, it's easy to write your own macro to do this, but because
it deals with multiple values, I have a feeling that this could be
done more efficiently by the compiler implementor.
dave
David Bakhash <·····@alum.mit.edu> writes:
> Hi,
>
> I'm wondering why MULTIPLE-VALUE-BIND doesn't allow you to specify
> default values. This change wouldn't even interfere with the current
> definition. So, for example, if you wanted to do:
>
> (multiple-value-bind (x (y 0)) (compute-1-or-maybe-2-values)
> ...)
Could you please provide an example because where this would be really
necessary? I'd write COMPUTE-1-OR-MAYBE-2-VALUES to always return 2
values (instead of returning only one value return two values, the
second being the default).
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
From: Tim Bradshaw
Subject: Re: MULTIPLE-VALUE-BIND question
Date:
Message-ID: <nkjpuca3s39.fsf@tfeb.org>
Janis Dzerins <·····@latnet.lv> writes:
>
> Could you please provide an example because where this would be really
> necessary? I'd write COMPUTE-1-OR-MAYBE-2-VALUES to always return 2
> values (instead of returning only one value return two values, the
> second being the default).
>
Well, you don't always have control over the number of values - you
may be calling code you didn't write. Then you have the whole issue
of knowing if it returned a 2nd value of NIL or no 2nd value.
But in fact we can do this in a terribly general way:
(multiple-value-call #'(lambda (x &optional (y nil yp))
...)
...)
which does much more than David asked for, I think. So
MULTIPLE-VALUE-BIND can probably be compiled very efficiently while
MULTIPLE-VALUE-VALUE-CALL is terribly general. I think that's quite a
good mixture.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Well, you don't always have control over the number of values - you
> may be calling code you didn't write.
If you call functions you didn't write, and without knowing what it
returns, I think you lose regardless of M-V-BIND's abilities.
--
Frode Vatvedt Fjeld
From: Tim Bradshaw
Subject: Re: MULTIPLE-VALUE-BIND question
Date:
Message-ID: <nkj66e1u2sp.fsf@tfeb.org>
Frode Vatvedt Fjeld <······@acm.org> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> If you call functions you didn't write, and without knowing what it
> returns, I think you lose regardless of M-V-BIND's abilities.
You may know it returns either one or two values, but not be able to
change it so it always returns two. Sure, you can write a wrapper, but
writing this wrapper requires you to solve the problem you already
have.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> You may know it returns either one or two values, but not be able to
> change it so it always returns two. Sure, you can write a wrapper,
> but writing this wrapper requires you to solve the problem you
> already have.
I fail to see why you would require some function to return two
values. Do you have an example?
--
Frode Vatvedt Fjeld
In article <··············@dslab7.cs.uit.no>,
Frode Vatvedt Fjeld <······@acm.org> wrote:
>Tim Bradshaw <···@tfeb.org> writes:
>
>> You may know it returns either one or two values, but not be able to
>> change it so it always returns two. Sure, you can write a wrapper,
>> but writing this wrapper requires you to solve the problem you
>> already have.
>
>I fail to see why you would require some function to return two
>values. Do you have an example?
The very first response in the thread suggested that instead of having the
caller do the defaulting in M-V-BIND, the function should return the
default value as its second value, rather than only returning one value.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, 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.
From: Tim Bradshaw
Subject: Re: MULTIPLE-VALUE-BIND question
Date:
Message-ID: <nkjwv6hmu0d.fsf@tfeb.org>
Frode Vatvedt Fjeld <······@acm.org> writes:
>
> I fail to see why you would require some function to return two
> values. Do you have an example?
>
The point is that I want to default the second value, and I want to be
able to do this when NIL is one of the possible second values. This
is the same as for things like GETHASH - you need to be able to
distinguish between a value that was NIL and no value.
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>Frode Vatvedt Fjeld <······@acm.org> writes:
>
>>
>> I fail to see why you would require some function to return two
>> values. Do you have an example?
>
>The point is that I want to default the second value, and I want to be
>able to do this when NIL is one of the possible second values. This
>is the same as for things like GETHASH - you need to be able to
>distinguish between a value that was NIL and no value.
Presumably this came up because you actually ran into a function that
returns an optional second value, and you needed to assign something other
than NIL in the M-V-BIND. Would you care to tell us what this function is
and why NIL is not an appropriate default value?
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, 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.
From: Tim Bradshaw
Subject: Re: MULTIPLE-VALUE-BIND question
Date:
Message-ID: <nkjvgm1mshz.fsf@tfeb.org>
Barry Margolin <······@genuity.net> writes:
>
> Presumably this came up because you actually ran into a function that
> returns an optional second value, and you needed to assign something other
> than NIL in the M-V-BIND. Would you care to tell us what this function is
> and why NIL is not an appropriate default value?
>
No, I was just trying to follow what the original poster (seemed to)
want. There doesn't seem to be any purpose to being able to default
in MVB otherwise.
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>Barry Margolin <······@genuity.net> writes:
>> Presumably this came up because you actually ran into a function that
>> returns an optional second value, and you needed to assign something other
>> than NIL in the M-V-BIND. Would you care to tell us what this function is
>> and why NIL is not an appropriate default value?
>No, I was just trying to follow what the original poster (seemed to)
>want. There doesn't seem to be any purpose to being able to default
>in MVB otherwise.
Sorry, when you said "I want", I assumed you *were* the original poster,
and didn't bother to scan back to verify this.
Like I said earlier, I think that most operators that have optional return
values do so because the extra values would be meaningless in the context
of the earlier values. For instance (ignore-errors
<body-that-returns-1-val>) doesn't return a second value (the error object)
when the body doesn't signal an error, since there's no error object to
return (however, this is probably a bad example, since IGNORE-ERRORS has to
be prepared to return as many values as its body does when there's no
error -- this one-value situation is just a special case).
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, 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.
From: Tim Bradshaw
Subject: Re: MULTIPLE-VALUE-BIND question
Date:
Message-ID: <nkju21lmqmb.fsf@tfeb.org>
Barry Margolin <······@genuity.net> writes:
>
> Sorry, when you said "I want", I assumed you *were* the original poster,
> and didn't bother to scan back to verify this.
>
Clumsy wording on my part, sorry.
> Like I said earlier, I think that most operators that have optional return
> values do so because the extra values would be meaningless in the context
> of the earlier values. For instance (ignore-errors
> <body-that-returns-1-val>) doesn't return a second value (the error object)
> when the body doesn't signal an error, since there's no error object to
> return (however, this is probably a bad example, since IGNORE-ERRORS has to
> be prepared to return as many values as its body does when there's no
> error -- this one-value situation is just a special case).
>
Yes, I'm finding it hard to think of a case where *I'd* actually want
to default a return value to non-NIL. I don't think I've ever used
MULTIPLE-VALUE-CALL in anger for this purpose. There's really not
much symmetry in my programs between this case and function arguments,
which I default all the time.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Barry Margolin <······@genuity.net> writes:
> >
> > Sorry, when you said "I want", I assumed you *were* the original poster,
> > and didn't bother to scan back to verify this.
> >
>
> Clumsy wording on my part, sorry.
>
> > Like I said earlier, I think that most operators that have optional return
> > values do so because the extra values would be meaningless in the context
> > of the earlier values. For instance (ignore-errors
> > <body-that-returns-1-val>) doesn't return a second value (the error object)
> > when the body doesn't signal an error, since there's no error object to
> > return (however, this is probably a bad example, since IGNORE-ERRORS has to
> > be prepared to return as many values as its body does when there's no
> > error -- this one-value situation is just a special case).
> >
>
> Yes, I'm finding it hard to think of a case where *I'd* actually want
> to default a return value to non-NIL. I don't think I've ever used
> MULTIPLE-VALUE-CALL in anger for this purpose. There's really not
> much symmetry in my programs between this case and function arguments,
> which I default all the time.
I suspect there is something deep here. It might be that for someone who
really programs in CPS style, things we think of as calls get modified to
be returns so that it does come up. But I equally expect that for those of
us who don't, that down is not symmetric with up. The naive presumption
might be that the receiver wants to do the defaulting, but it could be that
the innermost position in a call is the one with most specific knowledge,
and so we always do defaulting before returning values rather than after
because the callee has better knowledge of a good default than the caller.
Also, we do have a paradigm for defaulting that is hybrid. Consider GETF's
default value or GETHASH's. We could default them on the way up, but the
syntax would be more complicated, replicating common code rather than
consolidating it as in the way GETF works. That is,
(LET ((FROB (GETF X Y DEFAULT))) ...)
rather than
(MULTIPLE-VALUE-BIND& (&OPTIONAL (FROB DEFAULT)) ;[*]
(GETF X Y)
...)
I suspect if you study this carefully you'll find that in any case where
the caller might get back different multiple value patterns, such that
&optional and serious defaulting might be needed in the first place, it's
probably a common question that all callers have, and the callee is probably
just as happy to receive information that allows it to return the values
in the pattern wanted in the first place.
I suspect a continuation-oriented decomposition of this, for all it adds
symmetry of certain kinds, loses in its ability to capture this need.
Just a guess.
I don't think it's accidental, though, that we've not noticed much call for
this and I suspect there's *something* about our present design that is
compensating without our knowing. If not these elements I've cited, then
maybe something else.
[*] When &keywords were first introduced to Maclisp, in the late 1980's,
they weren't in DEFUN and *certainly* were not in LAMBDA. You had to
use DEFUN& to get them. It took a while before someone said "since
DEFUN& autoloads anyway and since there's no ambiguity of meaning,
why not just always use it even when only DEFUN is requested". I
picked the name MULTIPLE-VALUE-BIND& in honor of DEFUN&.
>>>>> "tim" == Tim Bradshaw <···@tfeb.org> writes:
>> Like I said earlier, I think that most operators that have
>> optional return values do so because the extra values would be
>> meaningless in the context of the earlier values. For instance
>> (ignore-errors <body-that-returns-1-val>) doesn't return a second
>> value (the error object) when the body doesn't signal an error,
>> since there's no error object to return (however, this is probably
>> a bad example, since IGNORE-ERRORS has to be prepared to return as
>> many values as its body does when there's no error -- this
>> one-value situation is just a special case).
tim> Yes, I'm finding it hard to think of a case where *I'd* actually
tim> want to default a return value to non-NIL. I don't think I've
tim> ever used MULTIPLE-VALUE-CALL in anger for this purpose.
tim> There's really not much symmetry in my programs between this
tim> case and function arguments, which I default all the time.
well, I wouldn't have asked if it weren't useful. Of course, we all
have our own styles of writing, and I don't see why it should be too
dificult to at least imagine that there is a non-pathological case
where you may want to bind variables to multiple values returned by a
function such that towards the end, if no values are returned, you can
have them bind to defaults.
One thing that makes it hard to write a language from scratch is that
the language authors must anticipate what most people want to do.
This is one of the reasons CL is so good -- they had many stepping
stone Lisps to learn from. But it ain't perfect, and the suggestion I
made, though perhaps not useful to most, would have been useful to me
-- at least this one time. I'm glad the 2nd value returned by GETHASH
came up, and even more so that GETF did. I feel that it's in this
vein that such a feature can is useful. I just wanted to know if it
was possible to suggest it for future versions of m-v-b.
dave
From: Tim Bradshaw
Subject: Re: MULTIPLE-VALUE-BIND question
Date:
Message-ID: <nkjd788trlx.fsf@tfeb.org>
David Bakhash <·····@alum.mit.edu> writes:
>
> well, I wouldn't have asked if it weren't useful. Of course, we all
> have our own styles of writing, and I don't see why it should be too
> dificult to at least imagine that there is a non-pathological case
> where you may want to bind variables to multiple values returned by a
> function such that towards the end, if no values are returned, you can
> have them bind to defaults.
Yes, that's why I emphasized *I* in my article.
Do you have a problem with using MULTIPLE-VALUE-CALL to do this, or -
better - a macro based on it? It would be pretty easy to define a
souped-up MULTIPLE-VALUE-BIND which detected defaulting arguments and
expanded to MULTIPLE-VALUE-CALL in that case but otherwise to
CL:MULTIPLE-VALUE-BIND. I can see that's a little clunky though (and
since it can be compiled away you could argue that the language should
support this).
--tim
From: Tim Bradshaw
Subject: Re: MULTIPLE-VALUE-BIND question
Date:
Message-ID: <nkjbsnsgx1z.fsf@tfeb.org>
Tim Bradshaw <···@tfeb.org> writes:
>
> Do you have a problem with using MULTIPLE-VALUE-CALL to do this, or -
> better - a macro based on it? It would be pretty easy to define a
> souped-up MULTIPLE-VALUE-BIND which detected defaulting arguments and
> expanded to MULTIPLE-VALUE-CALL in that case but otherwise to
> CL:MULTIPLE-VALUE-BIND. I can see that's a little clunky though (and
> since it can be compiled away you could argue that the language should
> support this).
>
In fact:
(defmacro multiple-value-bind+ (vars/defaults form &body code)
(if (every #'symbolp vars/defaults)
`(multiple-value-bind ,vars/defaults ,form ,@code)
(progn
(dolist (v vars/defaults)
(unless (or (symbolp v)
(and (consp v)
(null (cddr v))
(symbolp (car v))))
(error "~A is not a variable or (variable default)"
v)))
(loop for v/d in vars/defaults
for lv = (gensym)
if (symbolp v/d)
collect lv into lal
and collect `(,v/d ,lv) into lel
else ;consp v
collect `(,lv ,(second v/d)) into lal
and collect `(,(first v/d) ,lv) into lel
finally (return
`(multiple-value-call
#'(lambda ,(cons '&optional lal)
(let ,lel
,@code))
,form))))))
is such a macro. I haven't really tested it much. It's trying to be
clever to avoid issues with variables with names like &x and also to
get parallel rather than serial binding, hence most of the hair.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> (defmacro multiple-value-bind+ (vars/defaults form &body code) ...)
> is such a macro. I haven't really tested it much.
I recommend, in addition to checking symbol-ness, etc., that you also watch
for any of the symbols being members of lambda-list-keywords, since the
temptation may be to include &optional or &rest in this.
Of course, the other way to go is:
(defmacro multiple-value-bind& (lambda-list exp &body forms)
(let ((fn (gensym "FN")))
`(flet ((,fn (&optional ,@(remove '&optional lambda-list))
,@forms))
(declare (dynamic-extent #',fn))
(multiple-value-call #'fn ,exp))))
This one does let you use the lambda list keywords in their obvious ways.
(One might or might not want to force the &optional onto the front of the
lambda list, but it seems to be more compatible with the spirit of multiple
values to do so.)
[No, I didn't test it at all. Caveat emptor.]
From: Tim Bradshaw
Subject: Re: MULTIPLE-VALUE-BIND question
Date:
Message-ID: <nkjae3cgv9f.fsf@tfeb.org>
Kent M Pitman <······@world.std.com> writes:
>
> I recommend, in addition to checking symbol-ness, etc., that you also watch
> for any of the symbols being members of lambda-list-keywords, since the
> temptation may be to include &optional or &rest in this.
>
No, it copes (or should). The actual LAMBDA gets gensymed arg names
which are then bound with LET. Actually it's likely illegal to bind
them (?) but that should cause errors not weirdity.
Actually here's another version (I changed the name and added some
comments, pretty much).
(defmacro multiple-value-bind/defaults (vars/defaults form &body code)
;; Like MVB but will default values
(if (every #'symbolp vars/defaults)
;; simple case, can just use MVB itsels
`(multiple-value-bind ,vars/defaults ,form ,@code)
;; Hairy case. Need to cope with defaulted args (x default),
;; and make sure bindign is pll and it is OK to use &x names.
(progn
(dolist (v vars/defaults)
(unless (or (symbolp v)
(and (consp v)
(null (cddr v))
(symbolp (car v))))
(error "~A is not a variable or (variable default)"
v)))
(loop for v/d in vars/defaults
for lv = (gensym) ;surely #:&x is safe?
if (symbolp v/d)
collect lv into lal
and collect `(,v/d ,lv) into lel
else ;consp v
collect `(,lv ,(second v/d)) into lal
and collect `(,(first v/d) ,lv) into lel
finally (return
`(multiple-value-call
#'(lambda (&optional ,@lal)
(let ,lel
,@code))
,form))))))
--tim
In article <··············@alum.mit.edu>,
David Bakhash <·····@alum.mit.edu> wrote:
>well, I wouldn't have asked if it weren't useful.
Then why can't you give a concrete example, rather than the mythological
(function-that-returns-1-or-2-values) in your original post?
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, 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.
David Bakhash <·····@alum.mit.edu> writes:
> One thing that makes it hard to write a language from scratch is that
> the language authors must anticipate what most people want to do.
And the risk that if you add certain featurism, you will encourage people
to do something you don't want them to do.
> This is one of the reasons CL is so good -- they had many stepping
> stone Lisps to learn from. But it ain't perfect, and the suggestion I
> made, though perhaps not useful to most, would have been useful to me
> -- at least this one time. I'm glad the 2nd value returned by GETHASH
> came up, and even more so that GETF did. I feel that it's in this
> vein that such a feature can is useful. I just wanted to know if it
> was possible to suggest it for future versions of m-v-b.
Well, I speak for the committee even less nowadays than I used to because
I am no longer a member. However,
(a) You already have the power to add this yourself.
(b) It may be expensive to add primitively. I vaguely recall that it
was the sort of thing where giving you n values or the nth-value
defaulted cheap in some implementations, but knowing how many values
was being returned was not as cheap. I don't know if this was just
a problem for certain implementations or for all of them.
(c) Historically, the committee mostly hated adding little pieces of
featurism like this that are someone's pet project. What DID persuade
the committee was to see that a vendor had been convinced, and
preferrably several. When no vendor has ever experimented with the
feature and shown it to be (1) efficient and (2) something people
want, it was taken less seriously and was an uphill battle.
Your first battle in adding any new feature should be to get a vendor
to offer it as an extension.
Honestly, I don't think you've made a case for it being worth the effort.
No one seems to have come up with a single example where it has ever caused
any really material inconvenience to have things as they are now. It might
be that if it were there, people would use it; this was the case with
multi-methods, which many people didn't feel a need for before we added it.
But you still have to make the case. You've provided no examples even
of a hypothetical form.
Frode Vatvedt Fjeld <······@acm.org> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> > You may know it returns either one or two values, but not be able to
> > change it so it always returns two. Sure, you can write a wrapper,
> > but writing this wrapper requires you to solve the problem you
> > already have.
>
> I fail to see why you would require some function to return two
> values. Do you have an example?
GETHASH
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Frode Vatvedt Fjeld <······@acm.org> writes:
> I fail to see why you would require some function to return two
> values. Do you have an example?
Janis Dzerins <·····@latnet.lv> writes:
> GETHASH
Bad choice of wording on my part, I guess. I was not requesting
examples of functions that need to return two values (I'm certainly
not arguing against multiple values in general). Rather, given some
function known to return either one or two values, why would you need
to somehow coerce it to always return two values? What sort of
function would this be?
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@acm.org> writes:
>
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> > I fail to see why you would require some function to return two
> > values. Do you have an example?
>
> Janis Dzerins <·····@latnet.lv> writes:
>
> > GETHASH
>
> Bad choice of wording on my part, I guess. I was not requesting
> examples of functions that need to return two values (I'm certainly
> not arguing against multiple values in general). Rather, given some
> function known to return either one or two values, why would you need
> to somehow coerce it to always return two values? What sort of
> function would this be?
I think the conventional reason is because you imagine you are programming
in Scheme and you think return is the mirror of function call and that
if you can get wrong-number-of-args in function call, you might get that
in return, too. Certainly, if you use MULTIMPLE-VALUE-CALL with a fixed-arity
function this would be so. But in Scheme it is often painful to manage
optional args (there being no portable syntax for doing that; only for
doing rest args), so the pressure is on fixed-arity things by people with
a formalist enough background to want to manage multiple values. In CL,
though, we'd just do multiple-value-call on something with optional args
and really not care. And almost no one does multiple-value-call anyway.
In article <··············@alum.mit.edu>,
David Bakhash <·····@alum.mit.edu> wrote:
>Hi,
>
>I'm wondering why MULTIPLE-VALUE-BIND doesn't allow you to specify
>default values. This change wouldn't even interfere with the current
>definition. So, for example, if you wanted to do:
>
>(multiple-value-bind (x (y 0)) (compute-1-or-maybe-2-values)
> ...)
If you need this you can do it with M-V-CALL:
(multiple-value-call
(lambda (x &optional (y 0))
...)
(compute-1-or-maybe-2-values))
Most of the time when a function returns a variable number of values, it's
because the later values are irrelevant due to the earlier values. If the
function were defined to return that optional value all the time, it
probably would return NIL in these cases, which is what M-V-BIND will bind
the variable to when no value is returned.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, 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.