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

[Gabriel Dos Reis]

On Sat, Jun 19, 2010 at 8:46 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> I am greatly amazed at the improvements in type propagation -- which still
> can not be called liked that, but which does some minimal type inference --,
> probably because the stupid algorithm catches quite many problems already.
>
> However, precisely due to the simplicity of the current algorithms, one
> thing that may be a showstopper is that there is code around that looks like
> this
>    (when (stringp foo)
>       (replace foo faa ...))
>
> I am a bit lost here. On the one hand this is valid Lisp, even if FOO is
> inferred to have, say, an integer type. However the compiler will see that
> REPLACE gets arguments of the wrong type and will complain.
>
> In a sense what the developer is asking from us here is that we not only
> obey the type declarations but also ignore the unreachable code and probably
> also keep branch-specific type information, which is too much asking for the
> little infrastructure that is built right now.
>
> Alternatives:
> - Emit an error as we did so far. Maxima and other programs will refuse to
> build.
> - Emit a warning. Software having this problem built with ASDF will not
> build because of the warnings.
> - Emit a style-warning.
> - Emit a compiler note.
> - Somebody implements the remaining pieces in the compiler :-)
>
> Which alternative do you feel more comfortable with?
>

It is valid Lisp, then error is obviously not acceptable.
Any other form of diagnostic that leads to build error is also
too severe.  Obviously, miscompilation is not an option.
My question is: can ECL still generate correct codes?

-- Gaby