<div class="gmail_quote">On Thu, Dec 29, 2011 at 5:46 PM, Gail Zacharias <span dir="ltr"><<a href="mailto:gz@clozure.com">gz@clozure.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div id=":10s">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>

</blockquote><div><br></div><div>Precisely what I mean is that the current semantics is really inconvenient for library writers. I also believe that this change can be introduced at no cost for library maintainers because it effectively does not change the semantics at the safety levels that code are typically compiled (0 or default ones). Let me try to explain it further below.</div>

<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":10s">

<div>Why not let SPEED into the mix?  E.g. if SPEED > SAFETY then don't compile typechecks.</div><div><div class="gmail_quote"><div></div></div></div></div></blockquote></div><div><br></div>The issue is not SPEED, it is safety. Safety need not be sacrificed to gain speed. Moreover, the problem with this SAFETY vs SPEED thing is that it has no granularity at all. It is a simplistic view of the world which assumes that all code is the same.<div>

<br></div><div>Let me explain the situation with an ordinary library, say a regular expression parser. Somebody who writes the library has to understand that there are various types of routines or sections of code that she is going to write:</div>

<div><br></div><div>2- Code that handles user input (strings, lists which might be malformed, etc)</div><div>1- Code that handles internal data (structures that will not change, sealed classes, lists of known lengths)</div>

<div>0- Small sections of code that handles internal data and needs speed</div><div><br></div><div>I would expect that only 0 should be compiled with SAFETY = 0, and explicitly marked so. However, we also have 1 and 2, which typically 1 and 2 are going to coexist and sometimes appear intermixed in the same function. Here one must either resort to high safety levels for everything, or end up wrapping around different sections of code with (LOCALLY (... UNSAFE ...) ...) declarations. This is not good in my opinion.</div>

<div><br></div><div>The problem is that we are implicitly advocating that SAFETY = 0 is good for everything once the code is mature enough and you need speed, but such level implies much more than believing type declarations, it typically implies that the arguments to functions are not checked at all. Take (CAR (THE CONS X)). There are multiple ways in which this CAR call can be inlined. To get the optimal case in this situation where I am telling the compiler "believe me, this is a CONS", I may be opening the can of worms by lifting all type checks in other uses of CAR.</div>

<div><br></div><div>Why do I believe this does not really change the semantics in a significant way? First of all because apart from SBCL's declaration policy there is not an explicitly written commitment in any of the free (natively compiling) common lisps out there about the meaning of optimization settings. In such a panorama, I would guess that currently library maintainers more or less follow the approach of lowering safety levels to 0 in speed-critical code and leaving it at some default value that works with their favorite implementation elsewhere. See for instance CL-PPCRE</div>

<div><br></div><div><div>(defvar *standard-optimize-settings*</div><div>  '(optimize speed (safety 0)(space 0) (debug 1) (compilation-speed 0)  #+:lispworks (hcl:fixnum-safety 0))...</div><div><br></div><div>From the user's point of view, the approach seems to be: if safety level is zero, the compiler will make fast code, in default settings mode, I will get type checking. The PCL also suggests this, and it seems to be a common entry point for many new users. Moreover, users also cannot rely on CMUCL's or SBCL's or ECL's type checking behavior for function arguments, because they are not really standard, and manual type checking is required in most libraries.</div>

</div><div><br></div><div><div><div>OTOH, if one comes up with a set of sensible settings that users may choose from and which may be applicable throughout the library, without disrupting the current behavior at SAFETY 0 or default, then  the cost of adoption is zero.</div>

<div><br></div></div></div><div>I am just trying to figure out a non-disruptive way of choosing those settings, documenting them (<a href="http://ecls.sourceforge.net/new-manual/ch02.html#ansi.declarations.optimize">http://ecls.sourceforge.net/new-manual/ch02.html#ansi.declarations.optimize</a>), and perhaps even sparking a debate about it, so that there may be some more uniformity throughout implementations.</div>

<div><br></div><div>Cheers,</div><div><br></div><div>Juanjo</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>