Re: Weak Reference proposal

[Daniel Ehrenberg]

I think this proposal is currently at Stage 0, right? Do we typically
put Stage 0 proposals on the TC39 GitHub? My understanding was that
proposals typically get moved after Stage 2.

Dan

On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble  wrote:
> I have posted a stage 1 proposal for weak references in ES7 for your perusal
> and feedback.
>
> https://github.com/tc39/proposal-weakrefs.git
>
> Thanks to Mark Miller and the authors of earlier proposals for help with the
> document and content!  Finally thanks to a few intrepid early reviewers for
> their edits, comments, and feedback.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Daniel Ehrenberg]

On Mon, Aug 24, 2015 at 3:45 PM, Waldemar Horwat walde...@google.com wrote:
 On 08/24/2015 10:08, Jason Orendorff wrote:

 In math, -x² is -(x²), not (-x)². But as proposed for JS, -x**2 is
 (-x)**2.

 PHP, Python, Haskell, and D side with the traditional algebraic
 notation, against JS. Here's PHP:

  $ php -r 'print(-2 ** 2);'
  -4

 Python:

   -2 ** 2
  -4

 Haskell:

  Prelude -2 ^ 2
  -4

 The D grammar: http://dlang.org/grammar.html#UnaryExpression

 Let's switch.


 Let's not.  As I said at the last meeting, making ** bind tighter than unary
 operators would break x**-2.  And making it sometimes tighter and sometimes
 looser would be too confusing and lead to other opportunities for precedence
 inversion.

 Waldemar

Agreed that the precedence should not bind sometimes tighter and
sometimes looser is problematic.

I think following the way other languages solve the same problem is
more important for minimizing user surprise than any particular
expression looking especially good. Looking kinda similar to other
languages in surface syntax has been a major advantage of JS all
along.

Dan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: UInt8ClampedArray Bitwise operators?

[Daniel Ehrenberg]

On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote:
 Operator overloading or value types might make it look a lot prettier some 
 day (though iirc element assessor overloading was off limits), but you could 
 get pretty far by baking it into a compile-to-js language.

ES2015 already has element accessor overloading with proxies, right?
It's everything else that's missing.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Named Arrow Functions

[Daniel Ehrenberg]

I assume you mean more like this (without factorial):

 x.map((x) = do {
if (x = 1) {
1;
} else {
x * recur(x - 1)
}
});

One issue is that it's hard to add keywords to JavaScript at this
point. If they're not from the tiny set of remaining reserved words
(enum, anyone?), they can be users' identifiers, and have to be based
contextually on some enclosing syntax, like yield is.

Another downside is that then, arrow functions have a distinct and
less powerful method of recursing (e.g., nested functions won't be
able to see the binding to the outer one).

Dan

On Tue, Aug 11, 2015 at 5:30 PM, Leonardo Wolter leocwol...@gmail.com wrote:
 What about a clojure like recur hidden variable binded to the bottom-level
 function?

  x.map(factorial(x) = do {
 if (x = 1) {
 1;
 } else {
 x * recur(x - 1)
 }
 });

 2015-08-11 21:26 GMT-03:00 Daniel Ehrenberg dehrenb...@chromium.org:

 In addition to being hard to parse in general, I don't think this
 would play very well with the async/await proposal
 https://tc39.github.io/ecmascript-asyncawait/ , which wants to have
 arrow functions like

 async (x) = ...

 Because we can't count on async as a keyword, your proposal would
 create an ambiguity.

 On Tue, Aug 11, 2015 at 1:49 PM, Jacob Parker jacobparker1...@gmail.com
 wrote:
  I did look, but couldn’t find anything on named arrow functions were not
  included. I do sometimes find cases where I want recursion inside a class
  function definition, and still need access to `this`. Was it just seen as
  syntax bloat, or were there any complications to implementing it?
 
  Obviously a contrived example, but something like this (using do syntax
  too)
 
  x.map(factorial(x) = do {
  if (x = 1) {
  1;
  } else {
  x * factorial(x - 1)
  }
  });
 
  ___
  es-discuss mailing list
  es-discuss@mozilla.org
  https://mail.mozilla.org/listinfo/es-discuss
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: UInt8ClampedArray Bitwise operators?

[Daniel Ehrenberg]

Bits and bytes are fundamental to JavaScript too, which is why the
language has, for a long time, included operations like , , ,
, |, ^ and ~ on Numbers, exposing the ability to manipulate 32-bit
integers. This is comparable to what C provides. Like C, JavaScript
has a relatively minimal standard library, so collections of these are
not included in the standard library itself.

Uint8ClampedArray is more of a historical artifact than something you
should actually aim to use. Uint8Array is probably what you'd want to
get at as a basis for a user-level library.

On Tue, Aug 11, 2015 at 5:20 PM, Daniel Ehrenberg
little...@chromium.org wrote:
 Bits and bytes are fundamental to JavaScript too, which is why the
 language has, for a long time, included operations like , , ,
 , |, ^ and ~ on Numbers, exposing the ability to manipulate 32-bit
 integers. This is comparable to what C provides. Like C, JavaScript
 has a relatively minimal standard library, so collections of these are
 not included in the standard library itself.

 Uint8ClampedArray is more of a historical artifact than something you
 should actually aim to use. Uint8Array is probably what you'd want to
 get at as a basis for a user-level library.

 On Tue, Aug 11, 2015 at 11:55 AM, Michael McGlothlin
 mike.mcgloth...@gmail.com wrote:
 SIMD types appear almost as limited in size as using numbers. Often I need 
 to manipulate thousands or millions of bits efficiently so fumbling around 
 with numbers is messy.

 I've looked at several implementations on npm but none seemed very mature or 
 standard.

 I guess it's philosophical as much as anything. In my mind the heart of 
 programming is bits and bytes so I find it odd that most programming 
 languages treat bits and bytes as strange uncles. In my mind all other data 
 types are derived from bits and bytes so it should be possible to easily 
 derive my own types this way or see the bits behind the types that are 
 built-in.

 In this case I'm implementing a bit index (which is something I use a lot) 
 for quickly finding relationships in complex data. Often I want to mess with 
 bits for working with specifics of file formats and network protocols. When 
 working with large numbers it's nice to not worry about limits. And I work 
 directly with bits when doing electronics.

 I'm not surprised that it's not supported but it seemed to go with the idea 
 of a byte array so I was hopeful. And it seems more generally useful than 
 things like SIMD types.

 Thanks,
 Michael McGlothlin
 Sent from my iPhone

 On Aug 10, 2015, at 7:36 PM, Daniel Ehrenberg little...@chromium.org 
 wrote:

 SIMD types have bitwise operators, but SIMD.js exposes just fixed-size
 vectors that are optimized to what hardware can optimize certain
 operations for. A future extension (the long SIMD API) may operate
 on whole arrays. I wouldn't recommend using SIMD.js unless you really
 feel like you're taking advantage of the better performance, and the
 particular vector size works for your requirements.

 The point of SIMD is to expose higher-performance hardware features to
 users. You may want to use this for implementing bitwise operations in
 user code. However, if you don't need that, it may be enough for you
 to use existing operators  | ^ ~ etc, in a loop. A search on npm
 yields tons of bitarray libraries which probably do this already,
 though I haven't assessed how good they are.

 If you were getting at operator overloading in particular, operators
 are already well-defined on things like Uint8Array: Roughly speaking,
 they will call .valueOf() and, if that results in a Number they will
 do the operation on the underlying Number. There's no built-in valueOf
 method for that object, but you can always monkeypatch one in. Here's
 an example session in the V8 command-line shell:

 d8 Uint8ClampedArray.prototype.valueOf = function() { return 1 }
 function () { return 1 }
 d8 new Uint8ClampedArray([1, 2])  3
 8

 The downside of doing anything beyond existing npm packages and
 changing the language is that it increases complexity. What is the
 upside you have in mind to building it into the language?

 Have fun!
 Dan

 On Mon, Aug 10, 2015 at 4:35 PM, Isiah Meadows isiahmead...@gmail.com 
 wrote:
 Do SIMD types solve your problem?

 https://github.com/tc39/ecmascript_simd


 On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
 wrote:

 Would there be a downside to extending Bitwise operators to work with
 typed arrays such as UInt8ClampedArray? To me it seems natural to want to
 perform bit operations on these. Or is there a better way to make a BitSet
 that I'm missing?


 Thanks,
 Michael McGlothlin
 Sent from my iPhone
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

Re: Named Arrow Functions

[Daniel Ehrenberg]

In addition to being hard to parse in general, I don't think this
would play very well with the async/await proposal
https://tc39.github.io/ecmascript-asyncawait/ , which wants to have
arrow functions like

async (x) = ...

Because we can't count on async as a keyword, your proposal would
create an ambiguity.

On Tue, Aug 11, 2015 at 1:49 PM, Jacob Parker jacobparker1...@gmail.com wrote:
 I did look, but couldn’t find anything on named arrow functions were not 
 included. I do sometimes find cases where I want recursion inside a class 
 function definition, and still need access to `this`. Was it just seen as 
 syntax bloat, or were there any complications to implementing it?

 Obviously a contrived example, but something like this (using do syntax too)

 x.map(factorial(x) = do {
 if (x = 1) {
 1;
 } else {
 x * factorial(x - 1)
 }
 });

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: UInt8ClampedArray Bitwise operators?

[Daniel Ehrenberg]

I don't think my earlier mail went through, so I'm posing it below for
the record:



SIMD types have bitwise operators, but SIMD.js exposes just fixed-size
vectors that are optimized to what hardware can optimize certain
operations for. A future extension (the long SIMD API) may operate
on whole arrays. I wouldn't recommend using SIMD.js unless you really
feel like you're taking advantage of the better performance, and the
particular vector size works for your requirements.

The point of SIMD is to expose higher-performance hardware features to
users. You may want to use this for implementing bitwise operations in
user code. However, if you don't need that, it may be enough for you
to use existing operators  | ^ ~ etc, in a loop. A search on npm
yields tons of bitarray libraries which probably do this already,
though I haven't assessed how good they are.

If you were getting at operator overloading in particular, operators
are already well-defined on things like Uint8Array: Roughly speaking,
they will call .valueOf() and, if that results in a Number they will
do the operation on the underlying Number. There's no built-in valueOf
method for that object, but you can always monkeypatch one in. Here's
an example session in the V8 command-line shell:

d8 Uint8ClampedArray.prototype.valueOf = function() { return 1 }
function () { return 1 }
d8 new Uint8ClampedArray([1, 2])  3
8

The downside of doing anything beyond existing npm packages and
changing the language is that it increases complexity. What is the
upside you have in mind to building it into the language?

Have fun!
Dan

On Tue, Aug 11, 2015 at 5:24 PM, Brendan Eich bren...@mozilla.org wrote:
 Daniel Ehrenberg wrote:

 Uint8ClampedArray is more of a historical artifact than something you
 should actually aim to use. Uint8Array is probably what you'd want to
 get at as a basis for a user-level library.


 Thanks for posting this, Daniel. Just to be super-clear (and I was around
 when it was born), Uint8ClampedArray is *totally* a historical artifact (of
 the HTML5 canvas element). Avoid unless you really are doing canvas-y
 things.

 /be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Getting SIMD.js into the TC39 repository

[Daniel Ehrenberg]

Hi Brian, ES-Discuss,

The SIMD.js spec and polyfill still lives in John McCutchan's GitHub
account. How can we transfer this to the TC39 account in accordance
with ECMA's requirements?

Thanks,
Dan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Value types, SIMD and standardization stages

[Daniel Ehrenberg]

At the last TC-39 meeting, the understanding I got was, it's OK to
bring SIMD to Stage 4 before value types are there as long as we have
a general understanding that value types are on track and will be
consistent with SIMD. I have been looking into value types, and I
believe they can be done in a consistent way with SIMD's current API.
I was thinking of making a proposal with respect to them some time
around the November or January meeting.

My question is, would the current state of value types block SIMD from
getting to Stage 3 earlier than a more detailed value types proposal?
Given a complete spec, compliant implementations and tests, would it
be possible to move to Stage 3 as long as Stage 4 was held back for
ensuring that value types will be consistent?

Thanks,
Dan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Detached TypedArray access semantics

[Daniel Ehrenberg]

In the draft ES6 spec, getting or setting array indices on detached
TypedArrays raises a TypeError. However, both V8 and SpiderMonkey seem to
return undefined from reads and silently succeed on writes. These semantics
have probably been shipping for some time.

As an implementer, I'm not sure what to do. Does anyone have any
information on whether it'd break the web to throw an error in this case?
What went into the decision to make these accesses throw an error in the
spec rather than the Chromium/Mozilla semantics? If it would break the web,
then should the spec be changed to match reality?

Thanks,
Dan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss