Re <progv> the CLHS states: "If too few values are supplied, the remaining
symbols are bound and then made to have no value".
In LW the following occurs:
CL-USER 73 > (progv '(a b c d) (list 1 2 3 4) (list a b c d))
(1 2 3 4)
CL-USER 74 > (progv '(a b c d) (list 1 2 3 4 5 6) (list a b c d))
(1 2 3 4)
CL-USER 75 > (progv '(a b c d) (list 1 2 3) (list a b c d))
Error: The variable D is unbound.
1 (continue) Try evaluating D again.
I don't understand why the third example breaks. Doesn't the CLHS dictum
mean they're bound to <nil>?
Thanks for any insight.
Carl Taylor
Carl Taylor wrote:
> Re <progv> the CLHS states: "If too few values are supplied, the remaining
> symbols are bound and then made to have no value".
>
>
> CL-USER 75 > (progv '(a b c d) (list 1 2 3) (list a b c d))
>
> Error: The variable D is unbound.
> 1 (continue) Try evaluating D again.
>
>
> I don't understand why the third example breaks. Doesn't the CLHS dictum
> mean they're bound to <nil>?
>
I think nil is a perfectly good value. The situation is perhaps more
subtle than I understand, but I think the idea of the spec is that
"bound and then made to have no value" means that the previously
existing dynamic binding, if there were one, is overridden with a "not
bound".
The idea being that it is unbound in the dynamic extent of the progv
form, and the previous binding, if any, is restored when the dynamic
extent is exited.
That's the only sensible distinction I can make between "no value" and
"unbound."
Carl Taylor wrote:
> Re <progv> the CLHS states: "If too few values are supplied, the
> remaining symbols are bound and then made to have no value".
>
> In LW the following occurs:
>
> CL-USER 73 > (progv '(a b c d) (list 1 2 3 4) (list a b c d))
> (1 2 3 4)
>
> CL-USER 74 > (progv '(a b c d) (list 1 2 3 4 5 6) (list a b c d))
> (1 2 3 4)
>
> CL-USER 75 > (progv '(a b c d) (list 1 2 3) (list a b c d))
>
> Error: The variable D is unbound.
> 1 (continue) Try evaluating D again.
>
>
> I don't understand why the third example breaks. Doesn't the CLHS dictum
> mean they're bound to <nil>?
No, a variable having no binding and having the binding 'nil are two
different concepts. A variable that is unbound throws an error when it
is accessed, while a variable that is bound to 'nil will return nil when
it is accessed.
It's good that there is a way to programmatically unbind a symbol. If
you want to bind a symbol to nil with progv, do so explicitly.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Carl Taylor wrote:
>> Re <progv> the CLHS states: "If too few values are supplied, the
>> remaining symbols are bound and then made to have no value".
>>
>> In LW the following occurs:
>>
>> CL-USER 73 > (progv '(a b c d) (list 1 2 3 4) (list a b c d))
>> (1 2 3 4)
>>
>> CL-USER 74 > (progv '(a b c d) (list 1 2 3 4 5 6) (list a b c d))
>> (1 2 3 4)
>>
>> CL-USER 75 > (progv '(a b c d) (list 1 2 3) (list a b c d))
>>
>> Error: The variable D is unbound.
>> 1 (continue) Try evaluating D again.
>>
>>
>> I don't understand why the third example breaks. Doesn't the CLHS
>> dictum mean they're bound to <nil>?
>
> No, a variable having no binding and having the binding 'nil are two
> different concepts. A variable that is unbound throws an error when it
> is accessed, while a variable that is bound to 'nil will return nil
> when it is accessed.
Thanks for the clarification. But if the remaining symbols are first bound
and then made to have no value, what the devil are they first bound to???
And why such binding/unbinding gymnastics?
Carl Taylor
In article <······················@bgtnsc05-news.ops.worldnet.att.net>,
"Carl Taylor" <··········@att.net> wrote:
> Thanks for the clarification. But if the remaining symbols are first bound
> and then made to have no value, what the devil are they first bound to???
They're not bound to anything. Unfortunately, the word "bind" is used
in multiple ways. Most often it means to associate a value with a
variable, but it's also used to mean that the variable is temporarily
associated with a new value cell, and this is a case of the latter.
Technically, the latter is the true definition, but the value cell and
its contents are usually connected immediately so we often conflate the
two concepts.
You can think of (progv '(a) '() <body>) as doing something like this:
(let ((old-value (symbol-value 'a)))
(unwind-protect
(progn (makunbound 'a)
<body>)
(setf (symbol-value 'a) old-value)))
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Wed, 04 Jan 2006 01:10:13 GMT, "Carl Taylor" <··········@att.net> wrote:
> But if the remaining symbols are first bound and then made to have
> no value, what the devil are they first bound to??? And why such
> binding/unbinding gymnastics?
So that their previous values are restored when the PROGV is exited.
CL-USER 1 > (defparameter *foo* 42)
*FOO*
CL-USER 2 > (progv '(*foo*) '()
(handler-case
*foo*
(error (msg)
(format t "Oops: ~A" msg))))
Oops: The variable *FOO* is unbound.
NIL
CL-USER 3 > *foo*
42
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Wed, 04 Jan 2006 01:10:13 GMT, "Carl Taylor" <··········@att.net>
> wrote:
>
>> But if the remaining symbols are first bound and then made to have
>> no value, what the devil are they first bound to??? And why such
>> binding/unbinding gymnastics?
>
> So that their previous values are restored when the PROGV is exited.
>
> CL-USER 1 > (defparameter *foo* 42)
> *FOO*
>
> CL-USER 2 > (progv '(*foo*) '()
> (handler-case
> *foo*
> (error (msg)
> (format t "Oops: ~A" msg))))
> Oops: The variable *FOO* is unbound.
> NIL
>
> CL-USER 3 > *foo*
> 42
Got it. Many thanks to all respondents.
Carl Taylor
Carl Taylor wrote:
> Pascal Costanza wrote:
>
>> No, a variable having no binding and having the binding 'nil are two
>> different concepts. A variable that is unbound throws an error when it
>> is accessed, while a variable that is bound to 'nil will return nil
>> when it is accessed.
>
> Thanks for the clarification. But if the remaining symbols are first
> bound and then made to have no value, what the devil are they first
> bound to??? And why such binding/unbinding gymnastics?
This is probably an unfortunate wording caused by knowledge about how
this is typically implemented. The most straightforward way to implement
unbound variables is by having a "secret" unbound value which a binding
is checked against on each access.
It's also important to understand the difference between binding and
assignment.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
"Carl Taylor" <··········@att.net> writes:
> Thanks for the clarification. But if the remaining symbols are first bound
> and then made to have no value, what the devil are they first bound to???
> And why such binding/unbinding gymnastics?
Not definitive, but my speculation is that the wording was chosen to
make it clear that PROGV always produces a binding, which will then be
unbound (thus restoring the original value) when the PROGV form is
exited.
Just making it unbound might have led to confusion about an effect on
the original value, and since you can't directly bind a value to the
unbound value, they probably had to resort to the more cumbersome
formulation.
--
Thomas A. Russ, USC/Information Sciences Institute
On Wed, 04 Jan 2006 00:48:06 GMT, "Carl Taylor" <··········@att.net> wrote:
> Re <progv> the CLHS states: "If too few values are supplied, the
> remaining symbols are bound and then made to have no value".
>
> In LW the following occurs:
>
> CL-USER 73 > (progv '(a b c d) (list 1 2 3 4) (list a b c d))
> (1 2 3 4)
>
> CL-USER 74 > (progv '(a b c d) (list 1 2 3 4 5 6) (list a b c d))
> (1 2 3 4)
>
> CL-USER 75 > (progv '(a b c d) (list 1 2 3) (list a b c d))
>
> Error: The variable D is unbound.
> 1 (continue) Try evaluating D again.
>
> I don't understand why the third example breaks. Doesn't the CLHS
> dictum mean they're bound to <nil>?
I'm certainly not an authority on this but I think LispWorks'
behaviour is right. Here are some data points:
1. In CLtL2 (yeah, I know it's pre-ANSI) the sentence above reads:
"If too few values are supplied, the remaining symbols are bound
and then made to have no value; see MAKUNBOUND."
2. The second CLHS glossary entry for "value" is "an object associated
with a name in a binding," so "made to have no value" could be
interpreted in such a way that there is no object associated with
the name, i.e. that the variable with that name is unbound.
3. If the symbols were supposed to be bound to NIL I think the text
would say so. See for example the dictionary entry for
MULTIPLE-VALUE-BIND where it clearly says that "extra values of NIL
are given to the remaining vars."
4. I think in the context of PROGV it makes sense to make these
variables unbound.
But I agree that the description is confusing. I wonder why Steele's
helpful addition was removed.
HTH,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> 3. If the symbols were supposed to be bound to NIL I think the text
> would say so. See for example the dictionary entry for
> MULTIPLE-VALUE-BIND where it clearly says that "extra values of NIL
> are given to the remaining vars."
The wording on progv is unfortunate since it implies an order of
binding the variable to nil and then making it unbound. Since there is
no way for any other code to execute between the binding and the implied
makunbound, that nil binding cannot be sensed, so it wouldn't matter
except for this:
Compare the "Examples" comments in the ANS dictionary page for let,
which explains that the following code is not conformant:
The code
(let (x)
(declare (integer x))
(setq x (gcd y z))
...)
is incorrect; although x is indeed set before it is used, and is set
to a value of the declared type integer, nevertheless x initially
takes on the value nil in violation of the type declaration.
If a variable has a declared type that does not include nil, it is
_not_ conformant to set that variable to nil, even if that value is
never referenced. But it _is_ conformant to make that variable
unbound, because unbound has the meaning of "no value".
So I think the wording of progv is just sloppy, and the bound to nil
implicaation was not intended.
This distinction is actually important in CLOS. A slot can have a
declared type yet can be unbound in any particular instance without
that being a violation of the declaration. A slot type is a statement
about the possible values returned by slot-value, etc., but slot-value
on an unbound slot cannot return. In particular, a slot type is _not_
a restriction about some value the implementation actually stores in
some opaque structure that implements a standard-object. (A
standard-object is opaque, except for slot-value and friends.)
CLOS gets this right, in my opinion, and Java gets it wrong. If I
remember correctly, in Java the type system requires some nonesense
that a user-defined type always includes NULL as an element.