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

[Juan Jose Garcia-Ripoll]

On Sat, Jun 19, 2010 at 5:01 PM, Tobias C Rittweiler <tcr at freebits.de>wrote:

> In article
> <AANLkTikYgy1xjiEH9CfkEVsIEDg8ZvwjyYJ1-H-vti3N at mail.gmail.com>,
>  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.
>
> I'm not following. What's wrong in the call to REPLACE?
>

Sorry if I was not clear, but FOO was previously declared to have type
INTEGER and that makes the code unreachable, but it also makes the call to
REPLACE invalid. The problem is that we will not always be able to infer
that the code is not reachable, for instance this inference done right now
_after_ type propagation takes place. Furthermore, instead of STRINGP we
could have another user defined function.


> The compiler can infer that FOO inside the branch must have type STRING.
>

Doing this is not as easy as it sounds. Inferring types from conditional
expressions and branches is not only difficult, but it may also be
impossible when predicates are combined.


> My point is that the call to REPLACE is never questionable. The WHEN
> form may.
>

The call itself is questionable if it has arguments which were declared to
have another type.

Juanjo

-- 
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/6cc2e3d5/attachment.html>