To be clear I was talking about advanced pattern matching for exception handling. Y(probably)AGNI?
On Tue, 21 Mar 2017 at 05:08, Isiah Meadows <[email protected]> wrote: > It's possible to add a "[No LineTerminator here]" constraint when > necessary, as was done for async functions. > > As for pattern matching, if you start paying attention to features of > newer programming languages, especially those just getting past their > hype stage (like Kotlin, Rust, and Swift), that YAGNI argument is > starting to seem harder to accept. > > Pattern matching is to conditionals as async/await is to async tasks - > it lifts the logic from fairly imperative, low level form to a high > level, declarative form, with only a small loss of low-level control. > ----- > > Isiah Meadows > [email protected] > > > On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <[email protected]> wrote: > > Any future matching syntax would clearly support the special cases people > > want to codify now. It might be that the best possible syntax is lost, > but > > e.g. ASI alone is probably a much bigger cause of syntax showstoppers to > be > > worried about. IMO, let it build up, then we can start thinking about a > > syntax overhaul another day. The chances are that We Ain't Gonna Need It. > > > > On 19 March 2017 at 22:47, kdex <[email protected]> wrote: > >> > >> But then, we might be adding new syntax twice to solve the same problem. > >> First specifically, then generally. The latter likely using an entirely > >> different syntax, making the former syntax obsolete. > >> Why not start speccing out some details for an optional typing proposal > >> instead, so we can get the ball rolling for true pattern matching? > >> > >> On Sunday, March 19, 2017 11:18:25 PM CET Zach Lym wrote: > >> > > > >> > > I read that TC39 agreed on adding pattern matching to language in > >> > > March > >> > > 2013. 4 years later we don't have even stage 0 proposal - so I would > >> > > consider it to be a dead end or wishful thinking. > >> > > > >> > > >> > Exactly, this proposal has been kicking around for ~15 years but keeps > >> > getting deferred in favor of "something better." I would be all for a > >> > special syntax using type hints or targeting easier-to-optimize > subsets, > >> > but they can be added later. > >> > > >> > This proposal introduces the minimum number of features needed to > handle > >> > the dynamic nature of JS. > >> > > >> > Thank you, > >> > -Zach Lym > >> > > >> > On Sun, Mar 19, 2017 at 8:23 AM, kdex <[email protected]> wrote: > >> > > >> > > Well, there has been some discussion of potentially adding something > >> > > like > >> > > static type hints at some point in the future. > >> > > Pattern matching is a feature that inevitably requires type > >> > > information at > >> > > runtime. > >> > > > >> > > So as long as the "optional typing" story isn't dead, I would assume > >> > > that > >> > > pattern matching isn't quite dead either, it's just not in the > >> > > currently > >> > > possible scope of things. > >> > > ECMAScript wouldn't be the only language which would have taken > years > >> > > to > >> > > come around to implementing type hinting: IIRC Python got its type > >> > > hinting > >> > > feature pretty late, too. > >> > > > >> > > On Sunday, March 19, 2017 4:22:26 PM CET Michał Wadas wrote: > >> > > > Is there a serious push to add pattern matching to language? Does > >> > > > any > >> > > > popular dynamically typed language have pattern matching? > >> > > > I read that TC39 agreed on adding pattern matching to language in > >> > > > March > >> > > > 2013. 4 years later we don't have even stage 0 proposal - so I > would > >> > > > consider it to be a dead end or wishful thinking. > >> > > > > >> > > > On Sat, Mar 18, 2017 at 5:16 PM, kdex <[email protected]> wrote: > >> > > > > >> > > > > I'm not sure if embedding this idea into the language will make > >> > > > > future > >> > > > > ideas about true pattern matching harder to implement or not. > >> > > > > Destructuring assignments are pretty slow from what I've > measured, > >> > > > > and > >> > > > > they still made it in, so I hardly see performance being a > >> > > > > showstopper > >> > > here. > >> > > > > > >> > > > > On Saturday, March 18, 2017 12:18:22 PM CET Michael J. Ryan > wrote: > >> > > > > > The if condition doesn't need to be limited to instance of... > >> > > > > > > >> > > > > > catch (err if !isNaN(err.status)) > >> > > > > > > >> > > > > > Aside: entering code in a phone is hard... > >> > > > > > > >> > > > > > > `instanceof` doesn't work across realms (iframes, for > >> > > > > > > example). If > >> > > we > >> > > > > > > introduced conditional catch blocks, I'd want a more > reliable > >> > > matching > >> > > > > > > mechanism than instanceof. > >> > > > > > > > >> > > > > > > On Fri, Mar 17, 2017 at 5:01 PM, Zach Lym > >> > > > > > > <[email protected]> > >> > > > > wrote: > >> > > > > > > > >> > > > > > >> Firefox supports the following conditional `catch` syntax: > >> > > > > > >> > >> > > > > > >> try { > >> > > > > > >> let result = await (); > >> > > > > > >> } catch (e if e instanceof ErrorType) { > >> > > > > > >> ... > >> > > > > > >> } > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> This was originally implemented in Spidermonkey as part of > an > >> > > > > > >> ES > >> > > > > proposal > >> > > > > > >> around 2000, but it was rejected for unknown reasons [0]. A > >> > > > > > >> 2012 > >> > > > > email to > >> > > > > > >> this list suggesting standardization of the syntax was > passed > >> > > over in > >> > > > > favor > >> > > > > > >> of waiting for a generic pattern matching facility [0][1]. > >> > > > > > >> Later > >> > > > > > >> discussion suggests that the pattern matching proposal > would > >> > > > > > >> have > >> > > > > been very > >> > > > > > >> slow [2]. A proposal for a Java-like type-based conditional > >> > > > > > >> was > >> > > > > proposed in > >> > > > > > >> 2016, but was criticized for lacking generality [2]. > >> > > > > > >> > >> > > > > > >> If the above summary is accurate, I would like to try to > >> > > standardize > >> > > > > the > >> > > > > > >> vanilla syntax once again. It's imperative, general, and > >> > > > > > >> doesn't > >> > > > > preclude > >> > > > > > >> the use of any hypothetical pattern matching functionality. > >> > > > > > >> > >> > > > > > >> Javascript's control flow has improved dramatically in > recent > >> > > years: > >> > > > > > >> promises got rid of callbacks, `async`/`await` clipped > >> > > > > > >> promise > >> > > > > chains, and > >> > > > > > >> classes make it easy to create custom Error objects that > >> > > > > > >> preserve > >> > > > > > >> stacktraces. Conditional catch is the last bit of syntax > >> > > > > > >> needed > >> > > to > >> > > > > make JS > >> > > > > > >> look like it was designed to handle asynchronous functions. > >> > > > > > >> > >> > > > > > >> Thoughts? > >> > > > > > >> > >> > > > > > >> -Zach Lym > >> > > > > > >> > >> > > > > > >> [0]: https://esdiscuss.org/topic/conditional-catch-clause# > >> > > content-10 > >> > > > > > >> [1]: https://esdiscuss.org/topic/conditional-catch > >> > > > > > >> [2]: > >> > > > > > >> > https://esdiscuss.org/topic/error-type-specific-try-catch-bl > >> > > > > > >> ocks#content-14 > >> > > > > > >> > >> > > > > > >> _______________________________________________ > >> > > > > > >> es-discuss mailing list > >> > > > > > >> [email protected] > >> > > > > > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > > > > >> > >> > > > > > >> > >> > > > > > > > >> > > > > > > _______________________________________________ > >> > > > > > > es-discuss mailing list > >> > > > > > > [email protected] > >> > > > > > > https://mail.mozilla.org/listinfo/es-discuss > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > _______________________________________________ > >> > > > > es-discuss mailing list > >> > > > > [email protected] > >> > > > > https://mail.mozilla.org/listinfo/es-discuss > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > _______________________________________________ > >> > > es-discuss mailing list > >> > > [email protected] > >> > > https://mail.mozilla.org/listinfo/es-discuss > >> > > > >> > > > >> > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
