Automatic typing
JS
js.mdnq at gmail.com
Sun Jun 30 18:30:05 PDT 2013
On Monday, 1 July 2013 at 01:08:49 UTC, Kenji Hara wrote:
> 2013/7/1 JS <js.mdnq at gmail.com>
>
>> I am simply talking about having the compiler enlarge the type
>> if needed.
>> (this is mainly for built in types since the type hierarchy is
>> explicitly
>> known)
>>
>
> Just a simple matter, it would *drastically* increase
> compilation time.
>
> void foo()
> {
> auto elem;
> auto arr = [elem];
>
> elem = 1;
> ....
> elem = 2.0;
> // typeof(elem) change should modify the result of
> typeof(arr)
> }
>
> Such type dependencies between multiple variables are common in
> the
> realistic program.
>
> When `elem = 2.0;` is found, compiler should run semantic
> analysis of the
> whole function body of foo _once again_, because the setting
> type of elem
> ignites the change of typeof(arr), and it would affect the code
> meaning.
>
> If another variable type would be modified, it also ignites the
> whole
> function body semantic again.
>
> After all, semantic analysis repetition would drastically
> increase.
>
> I can easily imagine that the compilation cost would not be
> worth the small
> benefits.
>
> Kenji Hara
No, this would be a brute force approach. Only one "preprocessing
pass" of (#lines) would be required. Since parsing statement by
statement already takes place, it should be an insignificant cost.
arr is of of type *typeof(elem), when elem is known arr is
immediately known. One would have to create a dependency tree but
this is relatively simple and in most cases the tree's would be
very small.
The type of elem is known in one pass since we just have to scan
statement by statement and update elem's type(using if (newtype >
curtype) curtype = newtype). At the end of the scope elem's type
is known and the dependency tree can be updated.
The complexity of the algorithm would be small since each
additional *autoscope* variable would not add much additional
computation(just updating the type... we have to scan the scope
anyways).
More information about the Digitalmars-d
mailing list