On Sat, Jun 19, 2010 at 5:01 PM, Tobias C Rittweiler <tcr@freebits.de> wrote:
In article
<AANLkTikYgy1xjiEH9CfkEVsIEDg8ZvwjyYJ1-H-vti3N@mail.gmail.com>,
 Juan Jose Garcia-Ripoll
 <juanjose.garciaripoll@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