Chuck type inferencer
lex at cc.gatech.edu
Tue Jun 1 19:56:10 UTC 2004
"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
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
> 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.
More information about the Squeak-dev