Inline
On Sun, Mar 26, 2017 at 10:23 PM, Zach Lym <[email protected]> wrote: >> 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. > > Are you arguing that we should have skipped promises and gone straight > to async/await? No. My analogy was a bit more meta than that, and I was referring to the difference between promise chaining and async-await control flow - async-await abstracts over the details of task scheduling. Similarly, instead of low-level conditionals, pattern matching just abstracts over the details of conditional ordering. > > FWIW, this in itself is not a trivial change as it requires extra work > for the debugger. I get that it'd be difficult for the debugger to handle. > > > Thank you, > -Zach Lym > > > On Sat, Mar 25, 2017 at 6:29 PM, Isiah Meadows <[email protected]> wrote: >> I want advanced pattern matching, but not something specific to error >> handling. >> >> On Thu, Mar 23, 2017, 06:01 Alexander Jones <[email protected]> wrote: >>> >>> 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 >> ----- Isiah Meadows [email protected] _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
