typeof symbol (Was: Sept 19 TC39 Meeting Notes)

[Brendan Eich]

Uli Riehm wrote:
>
>     The simplest and clearest solution is to extend typeof so typeof
>     0L is "int64" and typeof 0UL is "uint64".
>
> If typeof 0L === ‘int64’, then because of it’s string nature typeof 0L 
> !== ‘number’. Isn’t that breaking compatability?

No. 0L is not yet in the language. It's a literal int64. Are you 
thinking of plain 0?

>  Maybe instanceof could be extended, first as binary operator also 
> working on string (and second as an unary operator returning the final 
> constructor’s global name)?
> var i = Int64(0L);

The name is int64, lowercase i. See 
http://wiki.ecmascript.org/doku.php?id=strawman:value_objects

> i instanceof ‘Int64’ === i instanceof Int64 // true
> i instanceof ‘Number’ === i instanceof Number // true
> // i instanceof ‘Object’ // true?

With rebased patch from 
https://bugzilla.mozilla.org/show_bug.cgi?id=749786 applied:

js> i = 0L
0L
js> i instanceof int64
true
js> i instanceof Number
false
js> i instanceof Object
true

An int64 is not a double-precision binary floating point number.

> instanceof i === ‘Int64’ // unary returning final constructor’s name 
> (for re-expression)

Making instanceof a unary as well as binary operator is not going to 
fly. For one thing, the 'of' in the name is broken English here. For 
another, it's too easy to mess up ASI or / or a comment and end up with 
a binary instanceof becoming unary unintentionally.

>  The typeof operator always issues an equal operator, so you can’t say 
> an int64 is also a number. Isn’t it? I believe typeof should think 
> it’s a number (like NaN or Infinity),

No.

Number is IEEE754 double, 53 bits mantissa. Not 64 bits. The types are 
not related.

> only something more detailed knows that it is an Int64 Number. Maybe 
> 0L is not an Object - for this I also like the post of Axel 
> Rauschmayer, where he proposes a ValueType function. instanceof could 
> say it’s not Object, but it is an ValueType instead. For example 0L 
> instanceof Int64 Number ValueType and (new Int64(0L)) instanceof Int64 
> Number Object.

That's nearly meaningless, though, and again fails cross-frame.

Please read the value objects proposal and consider the invariants from

https://bug749786.bugzilla.mozilla.org/attachment.cgi?id=655055&action=diff&collapsed=&context=patch&format=raw&headers=1

+ * Value objects include int64 and uint64 instances and support the expected
+ * arithmetic operators: | ^&  ==<  <=<<  >>  >>>  + - * / %, boolean test, ~,
+ * unary - and unary +.
+ *
+ * != and ! are not overloadable to preserve identities including
+ *
+ *  X ? A : B<=>   !X ? B : A
+ *  !(X&&  Y)<=>   !X || !Y
+ *  X != Y<=>   !(X == Y)
+ *
+ * Similarly,>  and>= are derived from<  and<= as follows:
+ *
+ *  A>  B<=>   B<  A
+ *  A>= B<=>   B<= A
+ *
+ * We provide<= as well as<  rather than derive A<= B from !(B<  A) in order
+ * to allow the<= overloading to match == semantics.
+ *
+ * The strict equality operators, === and !==, cannot be overloaded, but they
+ * work on frozen-by-definition value objects via a structural recursive strict
+ * equality test, rather than by testing same-reference. Same-reference remains
+ * a fast-path optimization.


Value objects have strong use-cases includling int64, uint64, bignum, 
complex, rational. These plus the two-way typeof-==/=== implication and 
the 0L == 0UL sane == behavior say typeof needs more result types. One 
can use instanceof, obviously, since there are always constructor 
functions, but typeof is universal (cross-frame). This is important.

/be

> Uli
> http://metadea.de/V/
> -----Ursprüngliche Nachricht-----
> From: Brendan Eich
> Sent: Sunday, September 30, 2012 3:25 AM
> To: Uli Riehm
> Cc: es-discuss
> Subject: Re: typeof symbol (Was: Sept 19 TC39 Meeting Notes)
> Uli Riehm wrote:
> > It’s bad... but ways better than typeof. I don’t think typeof should
> > be extended, it always returned lower cased names and not the upper
> > cased string,
> No one is proposing that typeof return capitalized strings or anything
> that might be a constructor name in a global object.
> The invariant I gave,
>    (typeof x == typeof y && x == y) <=> x === y
> helps keep typeof, == and === saner than otherwise. My argument builds
> on it by observing (independent observation) that users will expect 0L
> == 0UL but 0L !== 0UL. If that's true, then typeof 0L != typeof 0UL in
> order for the left-to-right implication direction to hold.
> That means typeof 0L and typeof 0UL can' t both be "object", in spite of
> what
> http://wiki.ecmascript.org/doku.php?id=strawman:value_objects
> says. The simplest and clearest solution is to extend typeof so typeof
> 0L is "int64" and typeof 0UL is "uint64".
> Programmers still use typeof heavily, much more than instanceof. The
> idea that it should not be extended on principle does not hold up, since
> IE has already done so, and more primitive relations in the language
> (the <=> invariant above) seem to require typeof extension, and it has
> been on our agenda for value types or value objects.
> So arguing "It's bad... but way better than typeof" based on a sense of
> smell is not enough. We need to reason from the invariant relations
> among operators in the language.
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss