"rrobbes" <rrobbes at info.unicaen.fr> wrote:
> But I was rather thinking of splitting the images into chunks, using 
> PAckageInfo for example, and maybe include package dependency information
> (I don't know how far TFNR went on this), so that you could use dependencies
> to analyse packages one at a time (assuming Kernel doesn't depend on 
> someting else ...) 

It's an interesting idea but I won't be going down this path any time
soon.  A huge question is the same one I mentioned in Stephane's talk of
type annotations: are the annotations trustworthy?  I don't think that
automatic dependencies will help more than what Chuck is already doing. 
However, it may well be possible to come up with a module system that
does

Keep in mind that even though modules are *statically* disjoint, they
may end up holding lots of pointers to each other *dynamically*. 
OrderedCollection's hold references to all kinds of things
*dynamically*, even though statically the OrderedCollection class might
not have many external references.  A type inferencer is trying to
predict this dynamic behavior, so it may be interested in these
dependencies that might not visible as normal package
inter-dependencies.


> Does that mean you don't program test-first ;-) ?
> Seriously, do you think, several tools could collaborate using a
> common knowledge base (I guess I should check Chuck ASAP) ? 

I use test-first but not all code I might download from the net does.

Anyway, *humans* can certainly use multiple sources of information.  And
tools can be written to provide an integrated display of all the
information they can derive.  There is nothing stopping a browser from
saying "Integer  < x < Number++" in order to show both lower and upper
bounds that it has found through different mechanisms.

Chuck does have a use for knowing some dynamic types, by the way,
because it can use them as a starting point.  It turns out that it is
good to start optimistic and then make the types progressively worse; if
one already has found dynamic types, then one may as well start there
instead of starting with the "Nothing" type.


> This kind of optimizations seems great, but also harder to do in Squeak,
> where a method could be added anywhere at any time ... but there is sure
> a lot of work to do in this field ... 

Yeah, whenever the code changes you have to throw away a lot of your
optimizations.  This adds some challenges.


-Lex