<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br><div><div>On 25 Nov 2012, at 23:58, Juan Jose Garcia-Ripoll <<a href="mailto:juanjose.garciaripoll@gmail.com">juanjose.garciaripoll@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_extra">On Sun, Nov 25, 2012 at 9:11 PM, Pascal Costanza <span dir="ltr"><<a href="mailto:pc@p-cos.net" target="_blank">pc@p-cos.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":1tq">Next error: slot-unbound errors should not be optimized away as far as I can tell. Or is there anything in specifications (CL or MOP) that allows implementors to do that?<br>
<div class="im"></div></div></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">There are various things conflicting here:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1* There was a typo in the macroexpander for ECL's core functions (not for user functions, AFAIK), which used instance-ref instead of safe-instance-ref. I am uploading a fix tonight, after some further tests.</div></div></blockquote><div><br></div><div>OK.</div><br><blockquote type="cite"><div class="gmail_extra">
<div class="gmail_extra">2* There was a problem in the compiler with optimization settings by which (optimize speed) implied (safety 0) in some contexts. Hopefully this has ben solved, too.</div></div></blockquote><div><br></div><div>OK.</div><br><blockquote type="cite"><div class="gmail_extra"><div class="gmail_extra">3* There is nothing in the Hyperspec or the MOP that explains how errors are handled under different optimization settings. Typically, a declaration of low safety leads to AREF, structure accessors and in this case slot accessors be inlined assuming that no error will take place. This is the interpretation I have used in various points in ECL. I believe it is sensible, but I am open to other arguments. This interpretation was activated by the point 2 above.</div>
</div></blockquote><br></div><div>I don't think the HyperSpec allows for that interpretation. The entry for slot-value is specific that slot-unbound is called when a slot is unbound, and the entry for slot-unbound specifies that the default method signals an error of type unbound-slot. There are no exceptions specified for unsafe code. This is actually important, since the whole slot-unbound and slot-missing protocols can be used to define reasonable semantics, for example to define hash-table-based slots, and user code needs to be able to rely on the correct workings of user-defined extensions here even for unsafe code.</div><div><br></div><div>However, the entry for defclass allows for adding new class options or slot options, with which you could enable such an optimization (which then becomes a safe assumption for user code).</div><div><br></div><div><br></div><div>Pascal</div><div><br></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div>--</div><div>Pascal Costanza</div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></div></body></html>