Mark S. Miller wrote:
> On Wed, Jul 17, 2013 at 8:55 AM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> 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 minimization of primitive concepts or
>     kinds, but I argue the better way on the web (given backward
>     compatibility) is not to mimimize at such a reductive level. Users
>     mostly ignore the boolean, number, and string wrappers, which are
>     unobservable in strict mode.
>
>
> Nit: They are not unobservable. Rather, strict code itself never 
> implicitly wraps.

Thanks, I meant that, but my point is users really don't run into 
boolean/Boolean, number/Number, and string/String complexity in the 
main. Yes, one must use String.prototype (not string.prototype, there's 
no 'string' of course), but such minor irregularities in languages are a 
lesser issue.

> However, for example,
>
>     ({}).valueOf.call(3) // 3 wrapper

Right.

>
>     Users do not want more wrappers, e.g., Uint64 for uint64. No
>     use-case is served by such beasts.
>
>     You might argue that "total cognitive load" is lower, but I reply
>     that since wrappers are almost completely unobservable and not
>     used explicitly, the load of having two types, symbol/Symbol,
>     bignum/Bignum, etc., is strictly higher.
>

I'm hoping you agree here!

/be

Mark S. Miller wrote:
> Nit: They are not unobservable. Rather, strict code itself never 
> implicitly wraps.

Thanks, I meant that, but my point is users really don't run into 
boolean/Boolean, number/Number, and string/String complexity in the 
main. Yes, one must use String.prototype (not string.prototype, there's 
no 'string' of course), but such minor irregularities in languages are a 
lesser issue.

> However, for example,
>
>     ({}).valueOf.call(3) // 3 wrapper

Right.

>> Users do not want more wrappers, e.g., Uint64 for uint64. No use-case is served by such beasts.
>
>> You might argue that "total cognitive load" is lower, but I reply that since wrappers are almost completely unobservable and not used explicitly, the load of having two types, symbol/Symbol, bignum/Bignum, etc., is strictly higher.

I'm hoping you agree here!