PROGV bindings and ordering
Jerry Boetje
spec is pretty thin and leaves me with a question about the sequencing
of binding. Both the list of variables and list of values is
evaluated. My question is - in what environment is the values form
evaluated? Is it the surrounding environment (doesn't include the
variables) or the new environment created by the PROGV? If the first,
I can ignore the new variable bindings when I evaluate the values
form. If the second, I could have a situation such as:
(let ((*x* 24))
(progv '(*x* *y*) (list 42 (+ *x* 17)) (list *x* *y*)))
=> first option: (42 41)
=> second option (42 59)
Thoughts?
Pascal Costanza
You can safely assume the first option. The spec says that the symbols
and values are evaluated, which implies that they can be arbitrary Lisp
expressions. If the second option would be the intended result, it would
be required to have a complicated evaluation semantics where first the
first symbol is computed, then the first value, then the second symbol,
then the second value, and so on. If the evaluation semantics were that
complicated, you could expect that they had spent some time on
explaining it in more detail, including corner cases, etc.
Here is a more illustrative example:
(defvar *x* 24)
(defun f () (list 42 (+ *x* 17)))
(defun test ()
(progv (read) (f)
(list *x* *y*)))
> (test)
(*x* *y*)
(42 41)
What should the evaluation semantics of Common Lisp look like so that
you get (42 59) as a result here? ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Jerry Boetje
>
> What should the evaluation semantics of Common Lisp look like so that
> you get (42 59) as a result here? ;)
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
Thanks. I usually find that it's a good thing to consult with a
master. :-)
Jerry
Kaz Kylheku
> I was looking into the spec for PROGV (next piece in CLforJava). The
> spec is pretty thin and leaves me with a question about the sequencing
> of binding. Both the list of variables and list of values is
> evaluated. My question is - in what environment is the values form
> evaluated? Is it the surrounding environment (doesn't include the
> variables)
Of course the surrounding environment.
It's not reasonable for a parallel binding construct to evaluate the forms
which give initial values in an environment in which the bindings already
exist.
(There is, of course, LET*, but in that one, a form giving
a value for a variable is evaluated in an environment in which
only the /previous/ variables already have bindings, not that
same variable itself, nor the lexically subsequent ones.
We could have a binding construct like that, but it would be troublesome; the
expressions could refer to variables which have not received their value yet.
Would these be initialized to nil first, keep the outer values,
or have indeterminate values that cause undefined behavior if used?
> or the new environment created by the PROGV? If the first,
> I can ignore the new variable bindings when I evaluate the values
> form. If the second, I could have a situation such as:
>
> (let ((*x* 24))
> (progv '(*x* *y*) (list 42 (+ *x* 17)) (list *x* *y*)))
> => first option: (42 41)
> => second option (42 59)
Okay, so if the second interpretation is in effect here, how is it that
(+ *x* 17) yields 59?
For that to be true, *x* has to have the value 42.
So you are saying that it works like this
Environment: *x* *y*
^ \
| \
| \
Form giving values: (list 42 (+ *x* 17))
Somehow, magically, the 42 goes into the environment under the variable *x*,
and then--in the same list expression!---this value is retrieved and
added to 17 to produce 59.
I.e. the behavior you are describing is like this:
(list (setf *x* 42) (+ *x* 17))
But actually there is no SETF call there; somehow this is happening
implicitly, which is an absurd behavior.
I suspect you may have somehow tripped over this:
Arguments and Values:
[ ... ]
values---a list of objects; evaluated.
Note that the word used is ``objects'', not ``forms''. A list of objects is
not a list of forms. This values argument to PROGV is a single expression which
is evaluated to produce a list of objects. The clause ``evaluated'' refers
to the list, not to the objects! Namely values is a list (of objects) which is
evaluated. It is not a list of forms that are evaluated. Admittedly, the
wording a little poor, and can easily trip up a non-native speaker. What
you are seeing here is kind of terse style of writing English sometimes used in
technical writing, condensed ``point form'' summaries of text, newspaper
headlines, etc. This terse dialect omits sentence subjects or objects (which
have to be understood and re-created by the reader), and also omits grammatical
conventions like articles. The word ``evaluated'' simply forms a sentential
clause on its own and you have to know what its antecedent is: what is it that
is evaluated. Is it the list, or the objects? Our big clue here is that objects
are not evaluated in Lisp, but forms (denoting objects) are. Plus years of
exposure to this terse dialect: the main thing in the previous sentence is
``list (of objects)'', so that's what goes with ``evaluated''.
So if values is '(1 2 3), the objects are 1, 2 and 3. If the values is (list
(+ 2 2) 'a), the objects are 4 and the symbol A. Unfortunately none of
the examples given clarify this because the objects are all self-evaluating.
Oops!