Immutable Types

[Sven Brauch]

Hey,

I forgot, there's also the "lite" version, which is what I'll have to
implement at least:

Every Declaration has a list of TypeHints. As soon as a type for a
Declaration can be guessed, a TypeHint is added to that declaration
which also points to the use it was created from. If the use is
deleted, the TypeHint is also deleted. If that declaration is
encountered in a subsequent pass, the list of types stored in the
TypeHints is added to the possible list of types for that declaration.
The sense of this is to track possible types for declarations over
multiple passes (currently they're just being overwritten).

That should be doable at least, shouldn't it? The advantage over the
complex solution is that it's probably easy to do and fast, and you
can simply get more accurate type guessing by doing more passes (thus
if you edit a few lines of a document you'll get very good type
guessing for free). The downside is obvious, if you have code which
contains many recursive function calls (for example, A(foo, bar) calls
B(foo, bar) which calls C(foo, bar)) you'd need many passes to guess
types accurately (3 or so passes in the example to determine the
argument types of C if you only know those of A at the beginning).

What do you think?
Bye,
Sven

2011/6/26 Sven Brauch <svenbrauch at googlemail.com>:
> Hi there!
>
> I've recently being thinking about a DUChain feature for supporting
> types which could change over time. The problematic case is this: You
> set some declarations type to an expression of which you do not *yet*
> know the type, but might know it later; for example, a variable "B" is
> assigned to a function argument "A" of unknown type. Later, the
> function in question is called and from the call a possible type for
> the argument can be guessed. The python plugin does now update the
> type of "A" to that type. However, there's currently no way to chain
> that change to "B"; another pass would be needed for that.
>
> I've been thinking about how to solve that problem, and I was thinking
> about something like immutable types. Those could be created in case a
> declaration whose type may be changed later is encountered, and for
> every use of such a type, a "client" would be registered for the
> expression in question to update the type of that expression. As soon
> as you change the immutable type, it would invoke all its clients and
> allow them to do their stuff. Such a client would usually consist of a
> node to visit with the expression visitor, and a declaration for which
> the type should be updated. Apart from that special behaviour when
> changing the type, such an immutable type would behave like a normal
> abstractType.
> Of course, any type that depends on an expression which contains an
> ImmutableType would need to be an ImmutableType, too, leading to ...
> most types being Immutable, actually.
>
> I created some example code which explains the idea in more detail here:
>                             http://paste.kde.org/88297/
>
> What do you think about that? Does it have any obvious logic mistakes
> (I'm not sure whether that can work at all)? Do you think it will work
> performance-wise? Is it possible to implement it without rewriting
> half of the DUChain? Can the type-system handle so many different
> types?
>
> Greetings,
> Sven
>