> 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.
I totally agree with you that a pattern matching API would be better, but unless you can come up with a syntax that can be enhanced progressively.... -Zach Lym >> >> >> 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
