<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">My read of the spec is that either
behaviour is allowable.<br>
<br>
DEFSTRUCT[1] says:<br>
<br>
"If a slot is not initialized in this way, it is initialized
by evaluating <i>slot-initform</i> in the slot description at the
time the constructor function is called."<br>
<br>
Which makes no reference to the environment in which the form
should be evaluated in.<br>
<br>
Later on it says:<br>
<br>
"It is as if the <i>slot-initforms</i> were used as <a
rel="DEFINITION"
href="http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_i.htm#initialization_form"><i>initialization
forms</i></a> for the <a rel="DEFINITION"
href="http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_k.htm#keyword_parameter"><i>keyword
parameters</i></a> of the constructor function"<br>
<br>
The page describing keyword arguments in ordinary lambda lists[2]
also makes no reference to which environment should be used for
initforms. <br>
<br>
I guess they didn't think about people using closures for
initforms when they were drawing it up?<br>
<br>
To side-step the issue I would invoke a closure from the initform
instead (if that's how you want to do it).<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://www.lispworks.com/documentation/HyperSpec/Body/m_defstr.htm">http://www.lispworks.com/documentation/HyperSpec/Body/m_defstr.htm</a><br>
[2]
<a class="moz-txt-link-freetext" href="http://www.lispworks.com/documentation/HyperSpec/Body/03_dad.htm">http://www.lispworks.com/documentation/HyperSpec/Body/03_dad.htm</a><br>
<br>
On 03/08/15 23:04, Peter Stirling wrote:<br>
</div>
<blockquote cite="mid:55BFE57D.7010100@pjstirling.plus.com"
type="cite">That makes no sense, the bindings in the let are
independent.
<br>
<br>
<br>
On 03/08/15 22:42, Laughing Water wrote:
<br>
<blockquote type="cite">It looks like you need a LET* to guarantee
the order of evaluation within your LET. Otherwise, it’s
undefined.
<br>
<br>
Laughing Water
<br>
<br>
<blockquote type="cite">On Aug 3, 2015, at 3:27 PM, Jean-Claude
Beaudoin <a class="moz-txt-link-rfc2396E" href="mailto:jean.claude.beaudoin@gmail.com"><jean.claude.beaudoin@gmail.com></a> wrote:
<br>
<br>
<br>
Please consider the following code:
<br>
<br>
(defparameter init-a 1)
<br>
<br>
(let ((init-a 42) (serial-no 0))
<br>
(defstruct foo (a init-a) (b (incf serial-no)))
<br>
(defun get-foo-serial-no () serial-no))
<br>
<br>
(defstruct (bar (:include foo)) (c 33) d)
<br>
<br>
When one loads the above and then try to call #'make-bar the
result
<br>
varies widely from one lisp implementation (clisp) to another.
<br>
<br>
clisp: (make-bar) --> #S(BAR :A 1 :B 1 :C 33 :D NIL)
<br>
ccl: (make-bar) --> <enter the debugger saying: "Unbound
variable: SERIAL-NO">
<br>
<br>
lispworks, allegro and sbcl also behave more or less like ccl.
<br>
<br>
What is the proper ANSI-CL behavior in this case here?
<br>
Is clisp right in evaluating the slot initform in its "proper"
lexical context?
<br>
Or is the correct behavior to replicate the slot initform
verbatim
<br>
in the sub-structure constructor regardless of its original
lexical context
<br>
like the others do?
<br>
<br>
I guess that this question has probably been asked before, in
a somewhat
<br>
distant past, but my google skills have not been sharp enough
to find it, sorry.
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
---
<br>
This email has been checked for viruses by Avast antivirus
software.
<br>
<a class="moz-txt-link-freetext" href="https://www.avast.com/antivirus">https://www.avast.com/antivirus</a>
<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>