Re: Are there any 64-bit number proposals under consideration?

[Joshua Bell]

http://littledan.github.io/int64.html

On Thu, Nov 12, 2015 at 11:41 PM, John Lenz  wrote:

> I should have been more precise, I meant 64-bit integers, not greater
> precision floating points (although, I'm sure that would be interesting
> too).
>
> On Thu, Nov 12, 2015 at 10:07 PM, Sam Ruby  wrote:
>
>> On Fri, Nov 13, 2015 at 1:00 AM, John Lenz  wrote:
>> > By this I mean, a usable type like by mere mortals, not generated C++
>> code.
>> >
>> > Maybe something like:
>> >
>> > var v64 = LongNumber.from('2e58');
>> > v64 = LongNumber.add(v64, 2);
>> >
>> > It doesn't have to be pretty just reasonably and perform closer to
>> native
>> > speed.
>>
>> Word of advice, whatever you do, do NOT mention IEEE 754.  Trust me.  :-)
>>
>> - Sam Ruby
>>
>
>
> ___
> 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: Array.prototype.contains

[Joshua Bell]

FWIW, Blink uses DOMStringList only in IndexedDB and apparently in
Location.ancestorOrigins



On Thu, Mar 6, 2014 at 1:59 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 3/6/14 4:49 PM, Brendan Eich wrote:

 What's with all the no one implements (including #3) stuff in specs?


 IDL Arrays in general are not implemented by anyone that I know of (and
 possibly ever).  They were a new concept added in WebIDL that hasn't really
 caught on with implementations.  In Gecko's case that was because we never
 got around to it, and it was simpler to use the infrastructure we needed to
 create anyway or already had for indexed getters (c.f. DOMStringList,
 NodeList, etc) than to create a bunch of new infrastructure for IDL Arrays.

 And then people realized that in some ways IDL Arrays are an attractive
 nuisance even if they were implemented, which made the priority on
 implementing them even less.

 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 has discussion
 that's worth reading, if people haven't already, about the various use
 cases that arise for arrays and arraylikes and how to best solve them.

  Are the specs new?


 Somewhat.


  Are we in a situation (even in #3, _pace_ Jonas)
 where the specs should be changed to reflect reality?


 Yes.  Need to figure out what reality is or should be, first.

 -Boris

 ___
 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: Exception type for invalid operations?

[Joshua Bell]

On Thu, Jan 30, 2014 at 8:25 AM, Domenic Denicola 
dome...@domenicdenicola.com wrote:

 I'm trying to design the [whatwg/streams spec][1] in the style of
 ECMAScript primitives, since I find that style more precise and idiomatic,
 and potentially in the future streams could become a language-level
 feature. Basically, I want to get ahead of the situation
 `TextEncoder`/`TextDecoder` find themselves in, as per [recent
 discussions][2].


Even following the link, I'm unsure if you're referring to the use of
DOMException with name EncodingError, or something else in that thread.
(If something else, can you ping me directly?)


 One thing I'm stuck on is what exception type to use for invalid
 operations. For example, trying to read from or write to a closed stream.
 None of the ECMAScript standard types---`EvalError`, `RangeError`,
 `ReferenceError`, `SyntaxError`, `TypeError`, and `URIError`---seem to
 match. Do I just give up and use `TypeError`, which seems to be the
 catch-all in most situations?


Distinct DOMException types used to be defined with a numeric enum. That's
changed to distinct strings (hence the DOMException w/ name
EncodingError, for example), and specs can add new types without
requiring additions to an enum tracked in the DOM spec.

Even with the ability to have feature-specific names error names, the
specific types don't communicate enough detail for developers to know
what's going on (e.g. InvalidStateError - uh, why?). In Chromium we're
trying to update the messages to indicate e.g. the method being called
(Failed to execute 'put' on 'IDBObjectStore': ...) in addition to the
specific details (The transaction is not active.). But at least with the
flexibility for a feature to define a specific error, you can point to the
line in the spec that explains why it's being thrown. Which argues for
allowing feature-specific error types and against an explosion of types
that need defining in ES where strings would be sufficient.

So... can we simply use Error() with documented |name| (for code to reason
about) and detailed |message| (for developers to log/debug) ?



 Or would it make sense to open ourselves up beyond the existing set, and
 define some kind of `InvalidOperationError`? The idea being that, *if*
 streams were to become an ECMAScript primitive, so would
 `InvalidOperationError`. (*If*, not when! Please don't read too much
 presumptuousness into my API design predilections.)

 Other languages seem to have something similar: [.NET's
 `InvalidOperationException`][3] and [Java's `IllegalStateException`][4]
 come to mind. But of course they have much deeper exception hierarchies,
 which I don't think we want to emulate.

 [1]: https://github.com/whatwg/streams
 [2]:
 http://esdiscuss.org/topic/need-a-champion-stringview-strawman#content-17
 [3]:
 http://msdn.microsoft.com/en-us/library/system.invalidoperationexception%28v=vs.110%29.aspx
 [4]:
 http://docs.oracle.com/javase/7/docs/api/java/lang/IllegalStateException.html
 ___
 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: Rename Number.prototype.clz to Math.clz

[Joshua Bell]

On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller erig...@google.com wrote:

 On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff 
 jason.orendo...@gmail.com wrote:

 At the risk of putting too many nails in the board...

 The rationale seems to propose that (0).clz() === 32, but the
 hypothetical uint64(0).clz() would return 64. That seems like a bad
 idea though. It's weird for two zero values to get such different
 behavior from the same method. It's weird for floating-point numbers
 to have a clz() method in the first place.

 Since these are two different mathematical functions, they should have
 different names: Math.clz32(zero) would be 32 no matter what type of
 zero you pass it; the hypothetical Math.clz64(zero) would of course be
 64. That way users can focus on the mathematical function being
 computed, rather than runtime types.

 Or maybe: flip the function around so that it returns the number of
 bits in the binary expansion of the value: Math.bitlen(15) === 4. This
 is just (32 - CLZ), so it effectively computes the same thing as clz.
 The advantage is that it extends naturally to integers of any size.


 +1. I like this flipping idea by far the best. It can be explained in
 terms of the number being denoted, without referring to the internal
 limitations of any particular representation. With this change, I agree it
 should be a static on Math.

 With this flipped idea, let's think through what the proper .bitlen
 answers are for fractions, negative numbers, NaN, +/- Infinity, and -0.0.


Would Math.bitlen(Number.MAX_SAFE_INTEGER) return 53 or 32?

(If 53, environments trying to emulate 32-bit ints on top of Number could
toss in yet another |0 or 0)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

[Joshua Bell]

Given that you can only use the proposed String.prototype.at() properly for
indexes  0 if you know the index of a non-BMP character or lead surrogate
by some other means, or if you will test the return value for a trailing
surrogate, is it really an advantage over using codePointAt / fromCodePoint?

The name at is so tempting I'm imagining naive scripts of the form for (i
= 0; i  s.length; ++i) { r += s.at(i); } which will work fine until they
get a non-BMP input at which point they're suddenly duplicating the
trailing surrogates.

Pushing people towards for-of iteration and even Allen's Array.from(
'팆팆팆'))[1] seems safer; users who need more subtle things have have
codePointAt
/ fromCodePoint available and hopefully the knowledge to use them.


On Fri, Oct 18, 2013 at 1:30 PM, Mathias Bynens math...@qiwi.be wrote:

 Please ignore my previous email; it has been answered already. (It was a
 draft I wrote up this morning before I lost my internet connection.)

 On 18 Oct 2013, at 11:57, Allen Wirfs-Brock al...@wirfs-brock.com wrote:

  Given that we have charAt, charCodeAt and codePointAt,  I think the most
 appropiate name for such a method would be 'at':
   '팆'.at(0)

 Love it!

  The issue when this sort of method has been discussed in the past has
 been what to do when you index at a trailing surrogate possition:
 
  '팆'.at(1)
 
  do you still get '팆' or do you get the equivalent of
 String.fromCharCode('팆'[1]) ?

 In my proposal it would return the equivalent of
 `String.fromCharCode('팆'[1])`. I think that’s the most sane behavior in
 that case. This also mimics the way `String.codePointAt` works in such a
 case.

 Here’s a prollyfill for `String.prototype.at` based on my earlier
 proposal: https://github.com/mathiasbynens/String.prototype.at Tests:
 https://github.com/mathiasbynens/String.prototype.at/blob/master/tests/tests.js
 ___
 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: Jan 31 TC39 Meeting Notes

[Joshua Bell]

Re: Maps and Sets comparators:

On Thu, Feb 7, 2013 at 8:27 AM, Rick Waldron waldron.r...@gmail.com wrote:

 # January 30 2013 Meeting Notes

 (snip)


 ARB: if we have a forth form of equality as default, we should be
 honest, name it, and make it available separately

 YK: Can we use === and disallow NaN as a key?

 WH: No.

 AWB: Why not?

 Comparison of the === vs Object.is case, w/r to NaN, +0/-0

 MM: Move `Object.is` to `Math.is`?

 WH: No, it accepts non-numbers

 WH: The longer we debate this, the more I want to just go with current
 implementations [that don't have a comparator parameter and always do the
 is semantics].

 RW: +1

 AWB: We should use this unnamed function as default, default is a fine
 name for it. If there is a demand, we can add it in the future.

 EA: We can skip the name...

 ARB: You might have circumstances where you do your comparison outside of
 the map.

 MM: General comparator argument, are we happy with this considering a
 hypothetical future that allows arbitrary equivalence class?

 WH: As long as it's an equivalence class, if you allow anything else, you
 run into trouble.


 **Conclusion/Resolution**
 - `Map( iterator = undefined, comparator = undefined )`
 - `Set( iterator = undefined, comparator = undefined )`

 - If the second argument is is, use Object.is
 - Otherwise, use ===

 ```js
 Map.defaultComparator( a, b )
 Set.defaultComparator( a, b )
 ```


Is that Otherwise clause correct, or should it be: Otherwise, use
Map/Set.defaultComparator

...where (based on the preceding text) the defaultComparator is like ===
w/r/t +/-0 but NaN's are equated?

i.e. Map.defaultComparator = function(a, b) {
  return ((a !== a)  (b !== b)) || (a === b);
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: then

[Joshua Bell]

On Fri, Nov 9, 2012 at 11:57 AM, Domenic Denicola 
dome...@domenicdenicola.com wrote:

  The idea is to not do the processing if the JSON parsing fails.

 ** **

 *From:* Cryptic Swarm [mailto:crypticsw...@gmail.com]
 *Sent:* Friday, November 9, 2012 11:55
 *To:* Domenic Denicola
 *Cc:* es-discuss@mozilla.org
 *Subject:* Re: then

 ** **

 The following should work? Finally expects a block statement, so need to
 wrap it in { }...

 ** **

 var info, processed;
 try {
 info = JSON.parse(json);
 } catch (exception) {
 console.log(Information JSON malformed.);
 } finally { try {
 processed = process(info);
 } catch (exception) {
 console.log(Error processing information.);
 }}

 On Fri, Nov 9, 2012 at 1:46 PM, Domenic Denicola 
 dome...@domenicdenicola.com wrote:

 The recent promise discussion prompted me to recall the following
 musing/proposal from Kris Kowal:

 https://github.com/kriskowal/q/wiki/On-Exceptions

 In short, there's a common code pattern that you can do with promises that
 you can't do with synchronous code. The proposal is for a language
 extension `then` that would allow synchronous code like this:

 var info, processed;
 try {
 info = JSON.parse(json);
 } catch (exception) {
 console.log(Information JSON malformed.);
 } then {
 processed = process(info);
 } catch (exception) {
 console.log(Error processing information.);
 }

 Since seeing this, I've run into a lot of situations where a `then` would
 come in handy. I wanted to see if anyone else thought this was a great
 idea, and if it has any chance as an ES7-level proposal.

 ___
 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


I believe you want that to desugar into:

var info, processed;
try {
info = JSON.parse(json);
try {
processed = process(info);
} catch (exception) {
console.log(Error processing information.);
}
} catch (exception) {
console.log(Information JSON malformed.);
}

... which is the synchronous equivalent of callbacks marching ever
rightward, and it is ugly and hard to read.

Like deeply-nested if statements, it's more readable if you put it into the
context of a function and follow an early exit coding style rather than a
only one exit coding style:

var info, processed;
try {
info = JSON.parse(json);
} catch (exception) {
console.log(Information JSON malformed.);
return;
}
try {
processed = process(info);
} catch (exception) {
console.log(Error processing information.);
return;
}

This still breaks up the normal flow of the function, but I don't see
this as significantly less readable than the proposed try/catch/then.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Joshua Bell]

On Fri, Nov 2, 2012 at 9:14 AM, Rick Waldron waldron.r...@gmail.com wrote:


 On Fri, Nov 2, 2012 at 11:25 AM, Allen Wirfs-Brock 
 al...@wirfs-brock.comwrote:

 There is also the compat issue with Mootools  with String contains...

 If we decided we needed to rename String contains then it might also
 impact what we call a similar Array method


 Perhaps it should be has instead of contains? Consistent with the
 other collections.


If you dig back far enough in this thread [1], you'll see that one of the
motivations for suggesting this was to be able to obsolete DOMStringList
[2] and quietly switch existing methods to returning plain old Arrays. That
would argue for keeping the name as contains.

But given that DOMStringList also has an explicit items method, and the
implications of the restriction to strings - e.g. calling d.contains(1) or
d.contains(undefined) follow WebIDL rules for stringifying the argument -
it is probably too late to actually remove DOMStringList from the platform.

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-February/020726.html
[2] http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMStringList
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Joshua Bell]

Bump.

I don't think Array.prototype.contains ever materialized on the proposals
page, and hasn't shown up in an ES6 draft.

Officially out for ES6, stuck in the queue, or dropped on the floor?

On Fri, Feb 24, 2012 at 4:40 PM, Rick Waldron waldron.r...@gmail.comwrote:

 Allen, thank you for the clarification there


 Rick


 On Feb 24, 2012, at 7:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:


 On Feb 24, 2012, at 11:09 AM, Rick Waldron wrote:



 On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson 
 erik.arvids...@gmail.comwrote:

 DOM4 added a new interface called DOMStringList for the sole reason
 that Array does not have contains. Before this the return type was an
 Array of Strings so we could use indexOf, map, forEach etc. Now that
 it is using a non Array we lost all of that.


 Wouldn't the return type (or [[Class]]) still be restricted from using
 Array?

 From 8.6.2

 The value of the [[Class]] internal property is defined by this
 specification for every kind of built-in object. The value of the [[Class]]
 internal property of a host object may be any String value except one of
 Arguments, Array, Boolean, Date, Error, Function, JSON,
 Math, Number, Object, RegExp, and String.


 So it can't be an Array by name, right?


 It can be, as long as it really is a ES array.  host object doesn't mean
 any object created by the host.  It means new kinds of objects created by
 the host that implement primitive behaviors (generally internal methods)
 differently from what is specified by the ES spec.

 So, from the ES perspective, no problem.  When I originally asked the
 question I was thinking more about from the Web IDL perspective.  Does Web
 IDL require things (for example throwing if extra arguments are passed)
 that ES Arrays do not do.


 Allen


 ___
 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: Minutes from 10/5 internationalization ad-hoc meeting

[Joshua Bell]

On Mon, Oct 15, 2012 at 5:51 PM, Gillam, Richard gil...@lab126.com wrote:

  **

 *Encoding conversion and detection.*  Most of the time, text has already
 been converted to UTF-16 before it surfaces in JavaScript, so the use cases
 here basically all revolve around reading legacy file formats and
 communicating with external libraries that use a non-Unicode character
 encoding.  We tended to agree that these use cases will dwindle over
 time, so this functionality will decline in value over time.  The tables
 and code are also potentially big and complicated (depending on which/how
 many encodings an implementer chose to support, or we mandated support
 for), and we didn’t think we wanted all ES implementers to have to carry
 them around all the time.  Despite fairly strong objections from Google,
 we agreed this was out of scope and shouldn’t be in a general-purpose
 standard.


FYI -

To support those use cases within browsers, I drafted an API [1] for
encoding/decoding into/out of typed arrays, with plenty of input from the
whatwg list. Going forward, Anne van Kesteren will be integrating it into
his Encoding spec [2]..

I don't think this contradicts the above conclusions by the
internationalization effort - the primary use case for non-legacy data is
for encoding/decoding ES strings into/out of binary buffers as UTF-8. The
secondary use case is for parsing legacy data formats where the Web is the
target platform, not ES itself, so having this be a browser API makes sense.

Mozilla is apparently quite far along with an implementation.

[1] http://wiki.whatwg.org/index.php?title=StringEncoding
[2] http://encoding.spec.whatwg.org
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss