<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 10:12 PM, Peter Stirling <span dir="ltr"><<a href="mailto:peter@pjstirling.plus.com" target="_blank">peter@pjstirling.plus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>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" target="_blank"><i>initialization
          forms</i></a> for the <a rel="DEFINITION" href="http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_k.htm#keyword_parameter" target="_blank"><i>keyword
          parameters</i></a> of the constructor function"<br></div></div></blockquote><div><br></div><div>Later later on it says:</div><div><br></div> "The slot default init forms are evaluated in the lexical environment in which the defstruct form itself appears and in the dynamic environment in which the call to the constructor function appears."</div><div class="gmail_quote"><br></div><div class="gmail_quote">So the defstruct sees the local/lexical serial-no but a call to make-bar outside does not.<br><br>In between we get more clues: "The symbols which name the slots must not be used by the implementation as the names for the lambda variables in the constructor function, since one or more of thosesymbols might have been proclaimed special or might be defined as the name of a constant variable. "<div><br></div><div>Indeed, if one compiles the example provided, when one <i>compiles </i>(ACL has both an interpreter and compiler, and they vary)<i> </i>make-bar one learns:</div><div><br></div><div>   Warning: Free reference to undeclared variable serial-no assumed special.</div><div><br></div><div>I checked the spec on included structs but did not notice anything about included slot init-form evaluation, but I guess it makes sense that included slots be assembled and evaluated as if coded with the including struct.</div><div><br></div><div>-hk</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      <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 href="http://www.lispworks.com/documentation/HyperSpec/Body/m_defstr.htm" target="_blank">http://www.lispworks.com/documentation/HyperSpec/Body/m_defstr.htm</a><br>
      [2]
      <a href="http://www.lispworks.com/documentation/HyperSpec/Body/03_dad.htm" target="_blank">http://www.lispworks.com/documentation/HyperSpec/Body/03_dad.htm</a><div><div class="h5"><br>
      <br>
      On 03/08/15 23:04, Peter Stirling wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote 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 href="mailto:jean.claude.beaudoin@gmail.com" target="_blank"><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 href="https://www.avast.com/antivirus" target="_blank">https://www.avast.com/antivirus</a>
      <br>
      <br>
      <br>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Kenneth Tilton</div><div dir="ltr">54 Isle of Venice Dr<br><div>Fort Lauderdale, FL 33301</div><div><br></div><div><a href="mailto:ken@tiltontec.com" target="_blank">ken@tiltontec.com</a></div><div><a href="http://tiltontec.com" target="_blank">http://tiltontec.com</a><br></div><div><span style="font-size:12.8000001907349px">@tiltonsalgebra</span><br></div><div><br></div><div>646-269-1077</div><div><br></div><div>"In a class by itself." <i>-Macworld</i></div><div><br></div><div><br></div></div></div></div></div></div>
</div></div>