Just try

It'd be nice if you could just do try {} without all the catch and finally stuff because about half the time the logic is simpler if I can just put all the error handling code in one place at the end. I end up with a lot of empty catch (err){} laying around waiting to break something. And using

Re: Swift style syntax

Having Op for all operator functions would be a good call. Probably better than adding Bitwise, Logic, etc just from the point of view of not filling up the namespace to much. I think short names would be fine so long as they were readable. So leftShift could be lShift but lsh is probably to

Re: Swift style syntax

It'd be simple to just define all operators as function​s and the actual operator is just syntaxial sugar. And then if you wanted to pass the operator you'd simply pass it's function around like you would any other function. Even your `Math.['>']` seems far safer than `Math.>` or just `>` but I'd

Re: Curried functions

I dislike that syntax because it makes the order of operations mysterious. I like the idea of currying but it should always be clear what is going on. A couple parentheses would make things a lot more obvious. On Thu, Oct 15, 2015 at 8:02 AM, Mark S. Miller wrote: > const

Re: Re: Additional Math functions

Why include numbers at all? Some people only manipulate strings so why not leave numbers to a third-party library that might be better? Or maybe we should use a string type that randomly drops lowercase characters because uppercase is good enough for many people. People that want to keep those

Re: Object id, hash, etc?

( this ); } if ( !primatives.has( this ) ) { primatives.set( this, ++OBJECT_ID ); } return primatives.get( this ); } On Wed, Sep 9, 2015 at 8:14 AM, Michael McGlothlin < mike.mcgloth...@gmail.com> wrote: > I think using WeakMaps is a good idea. Using a Symbol will keep from >

Re: Object id, hash, etc?

special - does it have some negative factor that should make using it less attractive?  Michael McGlothlin > On Sep 9, 2015, at 5:36 AM, Andrea Giammarchi <andrea.giammar...@gmail.com> > wrote: > > That's similar to the Labeler proposed by Mark, except it needs to search for

Re: Object id, hash, etc?

chain which is why I was using get and a second 'hidden' property. Using WeakMap seems like it'd fix the issue. Can't say I've used Object.assign much - will have to experiment with it. Thanks, Michael McGlothlin Sent from my iPhone > On Sep 9, 2015, at 7:34 AM, Andrea Giammarchi <andrea.g

Re: Object id, hash, etc?

hash of own props that were value types or frozen. Thanks, Michael McGlothlin Sent from my iPhone > On Sep 9, 2015, at 9:53 AM, Brendan Eich <bren...@mozilla.org> wrote: > > For posterity: > > http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes > http://wiki.ec

Re: Object id, hash, etc?

request. This is the logical complement to valueof, I >> think. And yes, for most ID use cases this isn't a good fit, but we're not >> talking about the general case, just the cases where a python style id() >> function *is* appropriate. >> >> Joe >> On Sep 8, 2015 9:0

Object id, hash, etc?

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

Re: Accounting for leap seconds for "this time value"

.  Michael McGlothlin > On Sep 3, 2015, at 5:06 AM, Claude Pache <claude.pa...@gmail.com> wrote: > > > That means that `Date.now()/1000` is the [Unix time] > (https://en.wikipedia.org/wiki/Unix_time), which can't represent leap > seconds. In particular, each minute is as

Better place for discussion?

implementation could be improved and would be interested in feedback. But I'd also be interested in discussion of how the language is evolving to make it easier. Thanks, Michael McGlothlin Sent from my iPhone ___ es-discuss mailing list es-discuss@mozilla.org

Re: System.import()?

the relationships from simple rules and lazy load the required bits as soon as possible. I've done that with running async code and it makes more sense to me than Promises.  Michael McGlothlin On Aug 19, 2015, at 5:46 AM, Guy Bedford guybedf...@gmail.com wrote: It's great to see more interest

Re: Proposal for a null coalescing operator

Another place JS would create a consideration is NaN. You might want that to play well with the operator. Possibly you could consider ?? for a wider range of nullish values and ??? for ONLY undefined. x = parseInt (a) ?? 42 x = a.nada ??? 42  Michael McGlothlin On Aug 16, 2015, at 10:32

Re: System.import()?

or XML it should be the same. If it's not JavaScript expose it as a stream and throw an error so alternate means can process it. Maybe implement it as an object that could be modified or inherited to leave it easily extensible. Thanks, Michael McGlothlin Sent from my iPhone On Aug 17, 2015

Re: Proposal for a null coalescing operator

I'd probably do something like x = y ?? ( parseInt(z) || undefined) ?? 42 Thanks, Michael McGlothlin Sent from my iPhone On Aug 17, 2015, at 5:01 AM, Herby Vojčík he...@mailbox.sk wrote: Michael McGlothlin wrote: Another place JS would create a consideration is NaN. You might want

Re: Proposal for a null coalescing operator

In JS it seems it'd be more useful if it worked with undefined not null. Thanks, Michael McGlothlin Sent from my iPhone On Aug 16, 2015, at 7:33 PM, Brandon Andrews warcraftthre...@sbcglobal.net wrote: https://en.wikipedia.org/wiki/Null_coalescing_operator Essentially x ?? y will return

Re: UInt8ClampedArray Bitwise operators?

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

UInt8ClampedArray Bitwise operators?

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

Re: Syntax shortcut for accessing properties on the current context (this)

. Maybe by itself it'd be equiv to this but could also be used to reference the function itself, the attached object, etc. #.prop, #function.prop, #object.prop, etc? Thanks, Michael McGlothlin Sent from my iPhone On Jul 27, 2015, at 8:23 AM, Nathaniel Higgins n...@nath.is wrote: Hi