Re: How primitive are Symbols? Bignums? etc

Brendan Eich wrote: I think this goes in the wrong direction. 'new' implies heap allocation and reference-type semantics. Value objects do not have either. Previously, from Claude Pache in April: https://mail.mozilla.org/pipermail/es-discuss/2013-April/029750.html """ The idea is simply to

Re: How primitive are Symbols? Bignums? etc

Allen Wirfs-Brock wrote: On Jul 22, 2013, at 6:30 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: ... I agree that int64(x) is nice for int64 (although I would expect such scalar values to me immutable regardless of how you create them). The intuition (supported by other languages) is that

Re: How primitive are Symbols? Bignums? etc

On Jul 22, 2013, at 6:30 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> ... > >> I agree that int64(x) is nice for int64 (although I would expect such >> scalar values to me immutable regardless of how you create them). > > The intuition (supported by other languages) is that 'new' hea

Re: How primitive are Symbols? Bignums? etc

Allen Wirfs-Brock wrote: My concern is that the pattern new T(x) //create a mutable instance: T(x) //create an immutable instance is a new one that we really don't reflect current usage in either the specification or in the wild, eg RegExp, Date. Those are definitely not value objects. More'

Re: How primitive are Symbols? Bignums? etc

On Jul 22, 2013, at 3:25 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> On Jul 20, 2013, at 4:14 PM, Brendan Eich wrote: >>> Allen Wirfs-Brock wrote: right, to all of the above. >> >> This would be a new idiom, and one that wouldn't necessarily apply to >> non-structured objects. This

Re: How primitive are Symbols? Bignums? etc

Allen Wirfs-Brock wrote: On Jul 20, 2013, at 4:14 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: I don't know, 'new Foo(args)' create a mutable Foo object 'Foo(args)' create an immutable Foo object isn't an idiom that we've had before Relax "mutable" in the first comment and

Re: How primitive are Symbols? Bignums? etc

On Jul 20, 2013, at 4:14 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> I don't know, >> 'new Foo(args)' create a mutable Foo object >> 'Foo(args)' create an immutable Foo object >> isn't an idiom that we've had before > > Relax "mutable" in the first comment and remove "ob

Re: How primitive are Symbols? Bignums? etc

Allen Wirfs-Brock wrote: I don't know, 'new Foo(args)' create a mutable Foo object 'Foo(args)' create an immutable Foo object isn't an idiom that we've had before Relax "mutable" in the first comment and remove "object" from the second comment and we have relevant precedent:

Re: How primitive are Symbols? Bignums? etc

On Jul 19, 2013, at 6:02 PM, Brendan Eich wrote: > Brandon Benvie wrote: >> Another factor I haven't seen mentioned but that I think is important is >> introducing a new primitive that has no literal form is another rough >> edge/inconsistency that will be confusing. Having to use a factory to

Re: How primitive are Symbols? Bignums? etc

Brandon Benvie wrote: Another factor I haven't seen mentioned but that I think is important is introducing a new primitive that has no literal form is another rough edge/inconsistency that will be confusing. Having to use a factory to make them makes me want to use `new` with that factory. But

Re: How primitive are Symbols? Bignums? etc

On Jul 19, 2013, at 11:37 AM, Andreas Rossberg wrote: > On 19 July 2013 18:52, Allen Wirfs-Brock wrote: >> On Jul 19, 2013, at 9:31 AM, Andreas Rossberg wrote: >>> You can't use proxies for symbols -- they are special in parts of the >>> semantics (and that includes their wrappers, if we want th

Re: How primitive are Symbols? Bignums? etc

Another factor I haven't seen mentioned but that I think is important is introducing a new primitive that has no literal form is another rough edge/inconsistency that will be confusing. Having to use a factory to make them makes me want to use `new` with that factory. But using `new` should alw

Re: How primitive are Symbols? Bignums? etc

On Fri, Jul 19, 2013 at 1:48 PM, Andreas Rossberg wrote: > On 19 July 2013 19:41, Dean Landolt wrote: >> I'm curious how symbols differ semantically from null-prototype, empty, >> frozen objects? > > They differ in that the extra cruft that's needed to represent random > objects is a complete was

Re: How primitive are Symbols? Bignums? etc

On Fri, Jul 19, 2013 at 2:48 PM, Andreas Rossberg wrote: > On 19 July 2013 19:41, Dean Landolt wrote: > > I'm curious how symbols differ semantically from null-prototype, empty, > > frozen objects? > > They differ in that the extra cruft that's needed to represent random > objects is a complete w

Re: How primitive are Symbols? Bignums? etc

On 7/19/2013 9:52 AM, Allen Wirfs-Brock wrote: Even if you could, I highly doubt that proxy performance will ever be up for the task, at least not for an implementation cost that isn't much higher than the special casing. Like I said, I don't see how this is a performance issue for Symbols exoti

Re: How primitive are Symbols? Bignums? etc

On Fri, Jul 19, 2013 at 12:31 PM, Andreas Rossberg wrote: > On 19 July 2013 18:17, Allen Wirfs-Brock wrote: > > You have to be able to support Proxy exotic objects so, I don't see why > you won't use that exact mechanism for Symbol objects. > > Because they are different. There is no useful unifi

Re: How primitive are Symbols? Bignums? etc

On Jul 19, 2013, at 9:31 AM, Andreas Rossberg wrote: > On 19 July 2013 18:17, Allen Wirfs-Brock wrote: >> You have to be able to support Proxy exotic objects so, I don't see why you >> won't use that exact mechanism for Symbol objects. > > Because they are different. There is no useful unified

Re: How primitive are Symbols? Bignums? etc

On Fri, Jul 19, 2013 at 11:48 AM, Allen Wirfs-Brock wrote: > > On Jul 19, 2013, at 6:54 AM, Andreas Rossberg wrote: > > > On 18 July 2013 18:16, Allen Wirfs-Brock wrote: > >> > > > >> In fact, the > >> conclusion/resolution doesn't even say that Symbols will be primitive > >> values. All of the

Re: How primitive are Symbols? Bignums? etc

On Jul 19, 2013, at 6:54 AM, Andreas Rossberg wrote: > On 18 July 2013 18:16, Allen Wirfs-Brock wrote: >> > >> In fact, the >> conclusion/resolution doesn't even say that Symbols will be primitive >> values. All of the bullet items listed there are apply equally to either >> symbols as primit

Re: How primitive are Symbols? Bignums? etc

On Jul 19, 2013, at 6:51 AM, Andreas Rossberg wrote: > On 18 July 2013 17:53, Brendan Eich wrote: >> > >> 3. Value object approach: no Symbol wrapper, typeof says "symbol", spec >> treats symbol as exotic object per latest draft. > > The implementation cost of every new exotic object is fairl

Re: How primitive are Symbols? Bignums? etc

On Jul 19, 2013, at 7:07 AM, Andreas Rossberg wrote: > > > How do we move forward? Unfortunately, I won't make it to the meeting > next week... At this point, the spec. is in a state where it is fairly easy to either stick with symbols as exotic objects or switch to symbols as a primitive typ

Re: How primitive are Symbols? Bignums? etc

Allen Wirfs-Brock wrote: On Jul 18, 2013, at 8:09 AM, Brendan Eich wrote: Andreas Rossberg wrote: On 18 July 2013 01:09, Brendan Eich> wrote: Brandon Benvie wrote: On 7/17/2013 4:02 PM, Brandon Benvie wrote: And this is how it currently works in the V8 implementati

Re: How primitive are Symbols? Bignums? etc

On Jul 18, 2013, at 12:56 AM, Andreas Rossberg wrote: > On 18 July 2013 01:09, Brendan Eich wrote: >> Brandon Benvie wrote: >>> >>> On 7/17/2013 4:02 PM, Brandon Benvie wrote: And this is how it currently works in the V8 implementation. The first thing I did testing it looked li

Re: How primitive are Symbols? Bignums? etc

On Jul 18, 2013, at 8:09 AM, Brendan Eich wrote: > Andreas Rossberg wrote: >> On 18 July 2013 01:09, Brendan Eich wrote: >>> Brandon Benvie wrote: On 7/17/2013 4:02 PM, Brandon Benvie wrote: > And this is how it currently works in the V8 implementation. The first > thing I did testi

Re: How primitive are Symbols? Bignums? etc

On Jul 18, 2013, at 5:22 AM, Claude Pache wrote: > IIUC, the problem with symbols-as-primitives is that, on one hand, wrapper > objects are not wanted, but, on the other hand, getting rid of wrappers leads > to complications. > > My suggestion is to allow wrapper objects to exist in the spec,

Re: How primitive are Symbols? Bignums? etc

Andreas Rossberg wrote: On 18 July 2013 14:22, Claude Pache wrote: IIUC, the problem with symbols-as-primitives is that, on one hand, wrapper objects are not wanted, but, on the other hand, getting rid of wrappers leads to complications. My suggestion is to allow wrapper objects to exist in

Re: How primitive are Symbols? Bignums? etc

Brendan Eich wrote: I actually would have preferred if 'new Symbol' worked, and that was what V8 implemented before the meeting. And just to be clear, what you implemented before the meeting, symbol primitive with Symbol auto-wrapper and no throw on ({}[new Symbol]) seems better. I think

Re: How primitive are Symbols? Bignums? etc

Andreas Rossberg wrote: On 18 July 2013 01:09, Brendan Eich wrote: Brandon Benvie wrote: On 7/17/2013 4:02 PM, Brandon Benvie wrote: And this is how it currently works in the V8 implementation. The first thing I did testing it looked like: var s = new Symbol(); var x = {}; x[s

Re: How primitive are Symbols? Bignums? etc

Andreas Rossberg wrote: On 17 July 2013 21:10, Brendan Eich wrote: We should not add more such user-facing pain if we can avoid it -- even if that means more implementor-facing pain (remember Mr. Spock's Kobayashi Maru solution ;-). An inconsistency between strings and symbols is both a user-

Re: How primitive are Symbols? Bignums? etc

IIUC, the problem with symbols-as-primitives is that, on one hand, wrapper objects are not wanted, but, on the other hand, getting rid of wrappers leads to complications. My suggestion is to allow wrapper objects to exist in the spec, but to completely hide them from the user by doing an implic

Re: How primitive are Symbols? Bignums? etc

Brandon Benvie wrote: On 7/17/2013 4:02 PM, Brandon Benvie wrote: And this is how it currently works in the V8 implementation. The first thing I did testing it looked like: var s = new Symbol(); var x = {}; x[s] = 'test'; I was surprised to find that this threw an error instead of

Re: How primitive are Symbols? Bignums? etc

On 7/17/2013 4:02 PM, Brandon Benvie wrote: And this is how it currently works in the V8 implementation. The first thing I did testing it looked like: var s = new Symbol(); var x = {}; x[s] = 'test'; I was surprised to find that this threw an error instead of doing the (to me) obv

Re: How primitive are Symbols? Bignums? etc

On 7/17/2013 3:58 PM, Claude Pache wrote: Le 17 juil. 2013 à 18:43, Andreas Rossberg a écrit : If users ignore them anyway, why would they care? If symbols are primitives with wrapper, they *must* care: They must know that `new Symbol` does not produce a new symbol, but some useless object.

Re: How primitive are Symbols? Bignums? etc

Le 17 juil. 2013 à 18:43, Andreas Rossberg a écrit : > > If users ignore them anyway, why would they care? If symbols are primitives with wrapper, they *must* care: They must know that `new Symbol` does not produce a new symbol, but some useless object. At least, `new Symbol` should either (

Re: How primitive are Symbols? Bignums? etc

Brendan Eich wrote: My perspective is that reasoning about `==`, and even to some extent `typeof`, is not that important, since they are both "broken." Let's cut this thread mercifully short. Language designers tending ECMA-262 cannot turn such a blind eye, period, full stop. It's fine if us

Re: How primitive are Symbols? Bignums? etc

Domenic Denicola wrote: From: Brendan Eich [bren...@mozilla.com] Yes, and I've written about why invariants matter on occasion -- perhaps you missed that :-P. Heh, 2008 was before my time. But generally yes, I certainly understand the importance of invariants. I am just not sure this partic

RE: How primitive are Symbols? Bignums? etc

From: Brendan Eich [bren...@mozilla.com] > Yes, and I've written about why invariants matter on occasion -- perhaps you > missed that :-P. Heh, 2008 was before my time. But generally yes, I certainly understand the importance of invariants. I am just not sure this particular invariant is somet

Re: How primitive are Symbols? Bignums? etc

Andreas Rossberg wrote: On 17 July 2013 17:55, Brendan Eich wrote: Andreas Rossberg wrote: As said above, we already have the primitive case, and you are just adding yet another kind of beast. I don't think that would be improving anything. On the contrary. This is an argument from minimizati

Re: How primitive are Symbols? Bignums? etc

Domenic Denicola wrote: From: Brendan Eich [bren...@mozilla.com] You still value the ```js (x == y&& typeof x == y)<=> x === y ``` invariant, right? That's the motivation for decimal, int64, etc. having their constructor-named "decimal", "int64", etc., typeof-result strings. You have bro

Re: How primitive are Symbols? Bignums? etc

Andreas Rossberg wrote: I doubt that there is a single implementation that would not want to special-case symbol representations. They will all have to deal with the extra complexity. Don't take this as a "you're wrong"-style absolute argument: We took this hit way back when, for E4X (to help

RE: How primitive are Symbols? Bignums? etc

From: Brendan Eich [bren...@mozilla.com] > You still value the > > ```js > (x == y && typeof x == y) <=> x === y > ``` > > invariant, right? That's the motivation for decimal, int64, etc. having their > constructor-named "decimal", "int64", etc., typeof-result strings. You have brought up this i

Re: How primitive are Symbols? Bignums? etc

Mark S. Miller wrote: I am uncomfortable expanding the typeof namespace. Where do these new names come from, and how do we avoid collision? You still value the (x == y && typeof x == y) <=> x === y invariant, right? That's the motivation for decimal, int64, etc. having their constructor-name

Re: How primitive are Symbols? Bignums? etc

On Jul 17, 2013, at 9:20 AM, Mark S. Miller wrote: > I am uncomfortable expanding the typeof namespace. Where do these new names > come from, and how do we avoid collision? > The typeof namespace has always been extensible and has historically been extended by some implementations. But the o

Re: How primitive are Symbols? Bignums? etc

On Jul 17, 2013, at 7:46 AM, Andreas Rossberg wrote: > On 16 July 2013 19:33, Allen Wirfs-Brock wrote: > ... >> Because MOP operations on symbols are never important, so that >> representation should be fine from the object perspective. For actual >> property access, its only the identify of

Re: How primitive are Symbols? Bignums? etc

Mark S. Miller wrote: On Wed, Jul 17, 2013 at 8:55 AM, Brendan Eich > wrote: Andreas Rossberg wrote: As said above, we already have the primitive case, and you are just adding yet another kind of beast. I don't think that would be

Re: How primitive are Symbols? Bignums? etc

Andreas Rossberg wrote: As said above, we already have the primitive case, and you are just adding yet another kind of beast. I don't think that would be improving anything. On the contrary. This is an argument from minimization of primitive concepts or kinds, but I argue the better way on the

Re: How primitive are Symbols? Bignums? etc

Allen Wirfs-Brock wrote: We're stuck with numbers, strings, and booleans and their corresponding wrappers. We don't need more special cases at that level. I should write an apologator (http://www-archive.mozilla.org/apology.html) for inflicting primitives as "non-objects" in those ten days i

Re: How primitive are Symbols? Bignums? etc

On Jul 16, 2013, at 4:34 AM, Andreas Rossberg wrote: > On 15 July 2013 19:44, Allen Wirfs-Brock wrote: >> The is primarily an internal spec. change. Many internal operations within >> the spec. require objects as parameters. This required inserting inserting >> explicit guards in p=many plac

Re: How primitive are Symbols? Bignums? etc

Allen Wirfs-Brock wrote: On Jul 15, 2013, at 10:30 PM, Brendan Eich wrote: Axel Rauschmayer wrote: The (x === Object(x)) test evaluates to true for value objects in this proposal, though. This may break code looking for "primitives" but we need to see what such code expects. Is it filtering ou

Re: How primitive are Symbols? Bignums? etc

On Jul 15, 2013, at 10:30 PM, Brendan Eich wrote: > Axel Rauschmayer wrote: >>> The (x === Object(x)) test evaluates to true for value objects in this >>> proposal, though. This may break code looking for "primitives" but we need >>> to see what such code expects. Is it filtering out the legacy

Re: How primitive are Symbols? Bignums? etc

Axel Rauschmayer wrote: The (x === Object(x)) test evaluates to true for value objects in this proposal, though. This may break code looking for "primitives" but we need to see what such code expects. Is it filtering out the legacy typeof-result primitives (plus "null"), trying to find values

Re: How primitive are Symbols? Bignums? etc

> The (x === Object(x)) test evaluates to true for value objects in this > proposal, though. This may break code looking for "primitives" but we need to > see what such code expects. Is it filtering out the legacy typeof-result > primitives (plus "null"), trying to find values for which typeof c

Re: How primitive are Symbols? Bignums? etc

Allen Wirfs-Brock wrote: On Jul 15, 2013, at 8:35 AM, André Bargull wrote: Allen (cc-ed) changed symbols back to objects in draft rev 16 (https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) will still work in ES6 to test for object types. Correct, Symbols as primitive v

Re: How primitive are Symbols? Bignums? etc

On Jul 15, 2013, at 9:40 AM, Andreas Rossberg wrote: > On 15 July 2013 18:24, Allen Wirfs-Brock wrote: >> On Jul 15, 2013, at 8:35 AM, André Bargull wrote: >>> Allen (cc-ed) changed symbols back to objects in draft rev 16 >>> (https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Obje

Re: How primitive are Symbols? Bignums? etc

On Jul 15, 2013, at 9:38 AM, Mark S. Miller wrote: > typeof x === 'function' and typeof x === 'object' are the current indications > of non-primitive types. What Allen is saying is that this set may expand, but > the typeof answers that indicate primitive value types will not. Allen was > enum

Re: How primitive are Symbols? Bignums? etc

On Jul 15, 2013, at 9:35 AM, Dean Landolt wrote: > > > > On Mon, Jul 15, 2013 at 12:24 PM, Allen Wirfs-Brock > wrote: > > Regarding, typeof. The right way to look at it is that the set of results > that correspond to non-object types will be fixed and includes only > ("undefined", "null"

Re: How primitive are Symbols? Bignums? etc

On Mon, Jul 15, 2013 at 12:24 PM, Allen Wirfs-Brock wrote: > > On Jul 15, 2013, at 8:35 AM, André Bargull wrote: > > Allen (cc-ed) changed symbols back to objects in draft rev 16 ( > https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess > Object(x) will still work in ES6 to test for ob

Re: How primitive are Symbols? Bignums? etc

On Jul 15, 2013, at 8:35 AM, André Bargull wrote: > Allen (cc-ed) changed symbols back to objects in draft rev 16 > (https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) > will still work in ES6 to test for object types. > Correct, Symbols as primitive values were just

Re: How primitive are Symbols? Bignums? etc

Ahh, thanks. Somehow I read that as `Object(undefined)` -> ObjectCreate(undefined)` -> throw, but that's not the case. On Mon, Jul 15, 2013 at 11:39 AM, Mark S. Miller wrote: > Object(undefined) would still not throw: > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1 step 1 > >

Re: How primitive are Symbols? Bignums? etc

> That's unpleasant. [...] Much old code will break. Indeed. I hadn't actually noticed that change until just now. It looks like ES6 code can take advantage of Object.isObject(), which seems to delegate the work to Type(*x*) [1]. It wasn't overwhelmingly clear to me, but I would assume `Object.

Re: How primitive are Symbols? Bignums? etc

Allen (cc-ed) changed symbols back to objects in draft rev 16 (https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) will still work in ES6 to test for object types. - André I see. That's unpleasant. In ES5, Object(x) can never throw, and so the code paths using |x === O

Re: How primitive are Symbols? Bignums? etc

> s === Object(s) This should throw a TypeError. In the case of a Symbol, `Object(*value*)` results in `ToObject(*value*)` [1]. And, in the case of Symbol, ToObject should throw a TypeError [2]. [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1 [2] http://people.mozilla.org/