[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
> 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
> > 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
> > high speed optimization settings, ECL may decide to expand the function.
> > other cases it may decide to just use an indirect call. Only the first
> > might be problematic: in case ECL unboxed the declared arguments and the
> > optimized implementation uses low level C, the resulting expressions
> > 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
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
* In the recursive traversal of the expression tree some things may happen
- The type of read-only variables may be determined uniquely by one
- The types of an argument may be made more precise by the surrounding
expressions (for instance THE, or a function whose arguments are
- 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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ecl-devel