[Ecls-list] Type propagator and "bogus" existing code

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sat Jun 19 15:32:53 UTC 2010


On Sat, Jun 19, 2010 at 5:14 PM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:

> If there is a declaration whose scope covers that conflicting
> inference (or uses),
> then I think the code is non-reachable.
>

Indeed. That is what the macroexpander that lead to that code was relying
on.


> Does not SBCL issue a warning in that case?
>

Probably it does, I can not check it right now, as it was part of a larger
Maxima build


>  > Typically ECL will detect the unused branches later at an expansion or
> > at an optimization stage, but if not, the outcome will vary. For low
> safety
> > high speed optimization settings, ECL may decide to expand the function.
> In
> > other cases it may decide to just use an indirect call. Only the first
> case
> > might be problematic: in case ECL unboxed the declared arguments and the
> > optimized implementation uses low level C, the resulting expressions
> might
> > actually be invalid. I am just wondering whether this can be prevented,
> > perhaps by marking the C1FORM as problematic.
>
> I am assuming that th inferred types are being cached by basic blocks, is
> that
> correct?
>

No, that would imply that we are having some kind of path-dependent
inference. Let me describe the things as they are right now

* Declared variables keep their type in a dedicated field.
* The intermediate code is a tree of expressions, each one having zero, one
or more arguments which are themselves expressions.
* Each form keeps a copy of the environment that was active at compilation
time. This environment may contain declarations, optimization settings, etc.
* The type of an expression is a values type stored in C1FORM-TYPE.
* This type is computed recursively as a function of its arguments.
* The computation is carried by dedicated functions or using global / local
function declarations.
* In the recursive traversal of the expression tree some things may happen
 - The type of read-only variables may be determined uniquely by one
assignement
 - The types of an argument may be made more precise by the surrounding
expressions (for instance THE, or a function whose arguments are
proclaimed...)
 - Some conflicts may be detected (as it is the case right now)
 - The output type of local functions (and probably global) is known and
made public (could be used to produce proclamations, as GCL does)

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100619/24bf6624/attachment.html>


More information about the ecl-devel mailing list