On Sat, Jun 19, 2010 at 5:14 PM, Gabriel Dos Reis <span dir="ltr"><<a href="mailto:gdr@integrable-solutions.net">gdr@integrable-solutions.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

If there is a declaration whose scope covers that conflicting<br>
inference (or uses),<br>
then I think the code is non-reachable.<br></blockquote><div><br>Indeed. That is what the macroexpander that lead to that code was relying on.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


Does not SBCL issue a warning in that case?<br><div class="im"></div></blockquote><div><br>Probably it does, I can not check it right now, as it was part of a larger Maxima build<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">
> Typically ECL will detect the unused branches later at an expansion or<br>
> at an optimization stage, but if not, the outcome will vary. For low safety<br>
> high speed optimization settings, ECL may decide to expand the function. In<br>
> other cases it may decide to just use an indirect call. Only the first case<br>
> might be problematic: in case ECL unboxed the declared arguments and the<br>
> optimized implementation uses low level C, the resulting expressions might<br>
> actually be invalid. I am just wondering whether this can be prevented,<br>
> perhaps by marking the C1FORM as problematic.<br>
<br>
</div>I am assuming that th inferred types are being cached by basic blocks, is that<br>
correct?<br></blockquote></div><br>No, that would imply that we are having some kind of path-dependent inference. Let me describe the things as they are right now<br><br>* Declared variables keep their type in a dedicated field.<br>


* The intermediate code is a tree of expressions, each one having zero, 
one or more arguments which are themselves expressions.<br>
* Each form keeps a copy of the environment that was active at compilation time. This environment may contain declarations, optimization settings, etc.<br>* The type of an expression is a values type stored in C1FORM-TYPE.<br>

* This type is computed recursively as a function of its arguments.<br>* The computation is carried by dedicated functions or using global / local function declarations.<br>* In the recursive traversal of the expression tree some things may happen<br>

 - The type of read-only variables may be determined uniquely by one assignement<br> - The types of an argument may be made more precise by the surrounding expressions (for instance THE, or a function whose arguments are proclaimed...)<br>

 - Some conflicts may be detected (as it is the case right now)<br> - The output type of local functions (and probably global) is known and made public (could be used to produce proclamations, as GCL does)<br><br>-- <br>
Instituto de Física Fundamental, CSIC<br>
c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>