It would take me a bit, and I've been contemplating syntax mentally for a while. But I may post a gist soonish
On Mon, Mar 27, 2017, 18:34 Zach Lym <[email protected]> wrote: > > 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
