[Ecls-list] ECL & Closer-mop

[Pascal Costanza]

Hi,

On 25 Nov 2012, at 23:58, Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> On Sun, Nov 25, 2012 at 9:11 PM, Pascal Costanza <pc at p-cos.net> wrote:
> 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?
> 
> There are various things conflicting here:
> 
> 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.

OK.

> 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.

OK.

> 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.

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.

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).


Pascal


--
Pascal Costanza



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121126/776b158e/attachment.html>