IDE support?

[François REMY]

The best way to avoid the "over-annotation" of codes is probably to teach 
users about WHEN or WHY they should add types guards. If you add the feature 
and don't explain what's her purpose and what specific scenarii it can 
solve, you'll get in trouble.

However, if you can coordinate with the whole community and publish a bunch 
of blog posts explaining how to "type efficiently", you'll get great 
results. But, in order to achieve that, all the implementations must be 
optimized for the same specific cases.

JavaScripters are acustomated to a untyped language. They will not type 
everthing because we know how handy it's to rely on compiler optimization. 
The most critical part will be to teach cross-compiler makers and people 
learning JavaScript after beeing used to, let's say, Java.

Anyway, another usage of type will be "automatic class instanciation from 
json data". For exemple, let's say I've a type defined like this :

    class A {
        var myFirstField : B;
        var mySecondField : B;
        function areEqual() : bool {
            if(myFirstField==null) { return mySecondField==null; }
            if(mySecondField==null) { return false; }
            return myFirstField.x == mySecondField.y;
        }
    };

    class B { int x; int y; }

You can do things like that :

    var myA = { myFirstField: {x:5, y:6}, mySecondField: {x:5, y:7} } as A;
    console.log(myA.areEqual());

François



-----Message d'origine----- 
From: Brendan Eich
Sent: Saturday, September 17, 2011 7:15 PM
To: Andreas Rossberg
Cc: es-discuss at mozilla.org
Subject: Re: IDE support?

On Sep 15, 2011, at 11:57 AM, Andreas Rossberg wrote:

> On 13 September 2011 16:48, Brendan Eich <brendan at mozilla.com> wrote:
>> On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote:
>>>
>>> * There are extra costs in space and time to doing the runtime analysis.
>>> * Compile time is runtime, so there are severe limits to how smart you
>>> can afford to get in a compiler.
>>
>> These are bearable apples to trade against the moldy oranges you'd make 
>> the world eat by introducing type annotations to JS. Millions of 
>> programmers would start annotating "for performance", i.e., gratuitously, 
>> making a brittle world at high aggregate cost.
>>
>> The costs born in browsers by implementors and (this can hit users, but 
>> it's marginal) at runtime when evaluating code are less, I claim.
>
> Depends on how good you want to optimize. Aggressive compilers can be
> really slow. There are limits to what you can bear at runtime.

You the user, yes -- good point. It's not just an implementor's burden.


>>> * The massive complexity that comes with implementing all this affects
>>> stability.
>>
>> This one I'm less sympathetic to, since we won't get rid of untyped JS up 
>> front. A sunk cost fallacy? If we could make a "clean break" (ahem), 
>> sure. Otherwise this cost must be paid.
>
> Well, the counter-argument would be that you wouldn't need to care
> about optimising untyped code as much, if the user had the option to
> switch to a typed sublanguage for performance.

I was really turned off by how AS3 users over-annotate. If we added "guards" 
and users turned to them "for performance", I'm afraid we'd see the same 
contamination.

Annotating might not even help performance -- in AS3, evaluation of 
arithmetic operators must widen from int to double, not wrap around 32 bits, 
so annotating int on storage types that annotate slots fetched and used via 
+, *, etc. can actually lose performance when storing back, since you have 
to use the FPU, or analyze and guard on overflow (as JS engines do today to 
avoid the FPU).

More analysis can help to stick to the ALUs but that works for untyped JS 
too.

Still, I agree that for performance-critical storage, annotations help. This 
is obviously so with typed arrays, which the fast VMs target with dedicated 
type inference and instruction selection machinery.

Is there a way to avoid the contamination problem we saw with AS3 during the 
ES4 days?


>>> * Wrt limits, even in the ideal case, you can only approximate the
>>> performance of typed code -- e.g. for property access you have at
>>> least two memory accesses (type and slot) plus a comparison and
>>> branch, where a typed language would only do 1 memory access.
>>
>> That's *not* the ideal case. Brian Hackett's type inference work in 
>> SpiderMonkey can eliminate the overhead here. Check it out.
>
> I'm actually pretty excited about that, and hope to see more on that
> front. Cool stuff.
>
> However, that ideal case is achieved in a relatively small percentage
> of cases only. Otherwise we should probably not see a (already
> impressive) 20-40% speed-up (IIRC), but rather something closer to
> 200-400%.

Oh, we're not done! The current work does not analyze the heap as 
aggressively as it might. We want objects that can be, say, four int32 
machine types in a row, to be inferred that way and represented that way. 
Currently such a type would take four "any" values in a row, plus the usual 
header for metadata.


> So the inferencer has to work with approximations and fallbacks. For a
> language like JS, where a lot of conceptual polymorphism, potential
> mutation, and "untypable" operations are going on, those
> approximations will remain omnipresent, except, mostly, in
> sufficiently local contexts.

Yes, and a key element of TI in SpiderMonkey is to put the "monster in the 
box" -- to avoid the untyped abstractions in one's JS polluting the whole 
inference. We try to fall back on runtime PICs and the other dynamic 
optimizations where we can. This means some guarding, or to avoid guards, 
some invalidation protocol overhead instead of guards. And low-level 
barriers to monitor all writes.


> Not to say that it is not worth extending the boundaries -- it
> definitely is. But it will only get you that far.

Farther enough than without, that it seems worth it. Again for me the big 
cosmic god-mode tradeoff is implementors working harder on these approaches, 
vs. throwing users to the wolves of type (over-)annotation.


>> Type annotations or (let's say) "guards" as for-all-time monotonic bounds 
>> on mutation are useful to programmers too, for more robust 
>> programming-in-the-large. That's a separate (and better IMHO) argument 
>> than performance. It's why they are on the Harmony agenda.
>
> Of course I'd never object to the statement that there are far better
> reasons to have typy features than performance. :) I just didn't
> mention it because it wasn't the topic of the discussion.

It's useful to be reminded of the performance wins that are possible with 
judicious use of type annotations, though. I expect we'll feel some "darts" 
(lol) in our backside on this point (heh).


>>> So despite all the cool technology we use these days, it is safe to
>>> assume that we will never play in the performance league of typed
>>> languages. Unless we introduce real types into JS, of course. :)
>>
>> Does JS need to be as fast as Java? Would half as fast be enough?
>
> No, it doesn't have to be as fast. Not yet, at least... I estimate we
> have another 3 years. ;)

Agreed!

/be
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss