Using declarations vs using THE is often a stylistic consideration, and while you may be able to get ECL-only users to accept your additional semantics, you might have trouble getting maintainers of portable libraries to observe this arbitrary distinction.<div>
<br></div><div>Why not let SPEED into the mix? E.g. if SPEED > SAFETY then don't compile typechecks.</div><div><br><div class="gmail_quote">On Thu, Dec 29, 2011 at 5:24 AM, Juan Jose Garcia-Ripoll <span dir="ltr"><<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">After struggling mentally with this for a few weeks, I would like to have some consultation before I introduce some changes in ECL -- not that I expect many users here, but at least some implementor-fellows and power users of other implementations.<div>
<br></div><div>My concerns right now relate to how declarations should be used by a compiler, and in particular how declarations interact with SAFETY levels. Please correct me if I am wrong, but I have seen more or less the following approaches</div>
<div><br></div><div>[a]- Most implementations blindly believe declarations below a certain safety level. Above it, they seem more or less useless.</div><div><br></div><div>[b]- SBCL takes declarations (and THE) as type assertions. For instance, in (LET ((Y (FOO X))) (DECLARE (FIXNUM Y))) ...) the assignment to Y would be checked to be a FIXNUM. This means the type declaration is actually enforced and believed and only at SAFETY 0 the checks are dropped (*)</div>
<div><br></div><div>In both cases one ends up with a model in which in order to truly believe a declaration and have no extra burden (assertions), one has to drop to SAFETY 0 in all code that is involved with it, which is a mess, because it might inadvertently affect other parts of the code. It is for this reason that I am considering an alternative model for ECL which would grade safety as follows</div>
<div><br></div><div>- Type declarations are always believed</div><div>- SAFETY >= 1 adds type checks to enforce them.</div><div>- SAFETY = 0, no checks.</div><div>- SAFETY = 1, the special form THE or additional proclamations on the functions can be used to deactivate the check. As in (LET ((Y (THE FIXNUM (FOO X))) ...)</div>
<div><br></div><div>This would allow one to keep most code safe, while deactivating some checks when they are really known to be true (**). Do you think this is useful/useless? The problem I see with this approach is that all code around is written for model [a] or [b], but I could not come up with something more sensible so far.</div>
<div><br></div><div>Juanjo</div><div><br></div><div>(*) Actually the checks are also deactivated when SBCL can infer the type of the value that is assigned to Y. This is somewhat contradictory, because (SETF Y (THE FIXNUM (FOO X))) would still generate a check, but proclaiming FOO to return a FIXNUM would completely bypass the check.</div>
<div><br></div><div>(**) Yes, indeed I know that LOCALLY exists for a reason, but it does more than THE. For instance, if I (LOCALLY (DECLARE (SAFETY 0)) (THE FIXNUM (FOO (SLOT-ACCESSOR X)))... this influences the safety of the code that accesses a structure, which is not good.</div>
<div><br></div><div>P.S.: Thanks to Paul Khuong for pointing out that SBCL behaves differently w.r.t. declarations.</div><span class="HOEnZb"><font color="#888888"><div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>
c/ Serrano, 113b, Madrid 28006 (Spain) <br>
<a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>
</div>
</font></span><br>_______________________________________________<br>
pro mailing list<br>
<a href="mailto:pro@common-lisp.net">pro@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
<br></blockquote></div><br></div>