Re: need some clarification on compile-time type vs. run-time type

2007-11-11 Thread Yuh-Ruey Chen
Brendan Eich wrote: > I'm going to summon Graydon and stand back now. > > /be > Right, I'll wait to reply in full until then. I just want to point out that the spec namespace isn't public. http://wiki.ecmascript.org/doku.php?id=spec:spec gives me a "permission denied" page.

roundTiesToEven

2007-11-11 Thread Jonathan Watt
Hi, I've noticed that rounding in the reference implementation is implemented using IEEE roundTiesToEven, but in browsers .5 values appear to round towards zero. Although roundTiesToEven is desirable from a computational point of view, there's likely a significant risk that changing to this method

Re: roundTiesToEven

2007-11-11 Thread liorean
On 11/11/2007, Jonathan Watt <[EMAIL PROTECTED]> wrote: > I've noticed that rounding in the reference implementation is implemented > using > IEEE roundTiesToEven, but in browsers .5 values appear to round towards zero. > Although roundTiesToEven is desirable from a computational point of view, >

Re: .newApply() ?

2007-11-11 Thread zwetan
On Nov 11, 2007 1:34 AM, Brendan Eich <[EMAIL PROTECTED]> wrote: [snip] > Got your back here ;-). Narcissus (http://lxr.mozilla.org/mozilla/ > source/js/narcissus/) wants this too, and it's going to end up > falling out of the reflection APIs: > > reflect::typeOf(this).reflect::construct(argum

Re: roundTiesToEven

2007-11-11 Thread Jonathan Watt
liorean wrote: > On 11/11/2007, Jonathan Watt <[EMAIL PROTECTED]> wrote: >> I've noticed that rounding in the reference implementation is implemented >> using >> IEEE roundTiesToEven, but in browsers .5 values appear to round towards zero. >> Although roundTiesToEven is desirable from a computatio

Re: need some clarification on compile-time type vs. run-time type

2007-11-11 Thread P T Withington
On 2007-11-11, at 00:57 EST, Brendan Eich wrote: > There are questions about exactly what strict mode analyses might be > mandated as normative if an implementation supports strict mode. This > may be clearer to Graydon and Cormac than to me, so I'd welcome their > comments. For example: > > f

Re: I'm confused about the design constraints on ES4

2007-11-11 Thread Mark Miller
Hi Brendan, There are many individual aspects of the the ES4 proposal that I like, many things I don't. All of which I hope to enumerate for this list over time. But overall my main distress is still the size of the language. At http://weblogs.mozillazine.org/roadmap/archives/2007/11/es4_news_an

Re: need some clarification on compile-time type vs. run-time type

2007-11-11 Thread Brendan Eich
The spec: namespace holds old, misleadingly inaccurate (for ES4) docs based on AS3. Nothing there has been touched in many moons. We made it inaccessible to avoid repeated confusion, and sure enough, when it was reopened inadventently again for a few days, almost immediately there was confu

Re: roundTiesToEven

2007-11-11 Thread Brendan Eich
On Nov 11, 2007, at 4:11 AM, liorean wrote: > On 11/11/2007, Jonathan Watt <[EMAIL PROTECTED]> wrote: >> I've noticed that rounding in the reference implementation is >> implemented using >> IEEE roundTiesToEven, but in browsers .5 values appear to round >> towards zero. >> Although roundTiesT

Re: I'm confused about the design constraints on ES4

2007-11-11 Thread Brendan Eich
On Nov 11, 2007, at 10:44 AM, Mark Miller wrote: Hi Brendan, There are many individual aspects of the the ES4 proposal that I like, many things I don't. All of which I hope to enumerate for this list over time. That would be great. It is one thing to sigh with despair at other people's tend

Re: roundTiesToEven

2007-11-11 Thread Jonathan Watt
Brendan Eich wrote: > I filed http://bugs.ecmascript.org/ticket/301. Thanks for that. I'll file issues in the bug tracker directly in future. Jonathan ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss

Re: need some clarification on compile-time type vs. run-time type

2007-11-11 Thread Yuh-Ruey Chen
Brendan Eich wrote: > > Anyway, we still have a similar confusion to what we had with > > |instanceof|, except this time it's all in |is|: > > > > // assume |b| is a class and |a| is an instance of it > > a is type b > > a is b > > > > Since both work, this can fool the user into thinking that the

Re: need some clarification on compile-time type vs. run-time type

2007-11-11 Thread Brendan Eich
On Nov 11, 2007, at 3:09 PM, Yuh-Ruey Chen wrote: > Sorry, I'm still not getting it. The upgraded |instanceof| will behave > exactly the same for the inputs non-upgraded |instanceof| works on. > There are new guarantees, but they in no way affect the original ones. They're stronger than the origi

Re: ES3 quasi incompatibilities

2007-11-11 Thread Garrett Smith
Function findDuplicate is more like "mark duplicates". The side effect is that it adds a __marker property to each object. As it stands, this function can not be called more than once. The second call might be passed a different array, but containing one of those objects that had the __marker left

InterType Declarations, Cross-Cutting - how to in ES4?

2007-11-11 Thread Garrett Smith
InterType Declarations InterType Declarations are a useful Iand popular) way of adding functionality to an object, usually to the prototype of a constructor. Lets say I have a class Widget that I want to borrow from: class Widget { private function Widget(){} static { getByNode : funct

Re: ES3 quasi incompatibilities

2007-11-11 Thread Yuh-Ruey Chen
Garrett Smith wrote: > JavaScript does not provide basic functionality for unique collections. > It's trivial to implement an efficient Set class even in ES3 (with certain restrictions on the "type" of the key) - just use objects which are pretty much specialized hash tables (maps from string t

Re: ES3 quasi incompatibilities

2007-11-11 Thread Garrett Smith
On Nov 11, 2007 7:18 PM, Yuh-Ruey Chen <[EMAIL PROTECTED]> wrote: > Garrett Smith wrote: > > JavaScript does not provide basic functionality for unique collections. > > > > It's trivial to implement an efficient Set class even in ES3 (with > certain restrictions on the "type" of the key) - just use

Re: ES3 quasi incompatibilities

2007-11-11 Thread Lars T Hansen
On Nov 11, 2007 6:01 PM, Garrett Smith <[EMAIL PROTECTED]> wrote: > Function findDuplicate is more like "mark duplicates". The side effect > is that it adds a __marker property to each object. As it stands, this > function can not be called more than once. The second call might be > passed a diffe

Re: need some clarification on compile-time type vs. run-time type

2007-11-11 Thread Brendan Eich
On Nov 11, 2007, at 4:26 PM, Brendan Eich wrote: > Part of the thinking in > resolving #103 in favor of type expression on right of 'is' was to > future-proof against a world where type and value expressions are > combined somehow. I don't believe that world will come to pass, > though. If it shou

Re: need some clarification on compile-time type vs. run-time type

2007-11-11 Thread Yuh-Ruey Chen
Brendan Eich wrote: > On Nov 11, 2007, at 3:09 PM, Yuh-Ruey Chen wrote: > > > Sorry, I'm still not getting it. The upgraded |instanceof| will behave > > exactly the same for the inputs non-upgraded |instanceof| works on. > > There are new guarantees, but they in no way affect the original ones. > >

generic function with structural types questions

2007-11-11 Thread Yuh-Ruey Chen
Given the following definitions: class C {var p: int}; type S1 = {p: int}; type S2 = {p: int, p2: double}; generic function foo(x); generic function foo(x: *) 0 generic function foo(x: C) 1 generic function foo(x: S1) 2 generic function foo(x: S2) 3 generic function foo(x: like S1) 4 generic funct

Re: need some clarification on compile-time type vs. run-time type

2007-11-11 Thread Brendan Eich
On Nov 11, 2007, at 10:41 PM, Yuh-Ruey Chen wrote: >> The key difference is that >> instanceof results can change over time for a given object on the >> left and plain old function on the right, while 'is' results cannot >> vary over the lifetimes of the same operands. > > If |is| is a purely runt