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 <k...@kdex.de> 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 <zach...@indolering.com>
> 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
> > >> es-discuss@mozilla.org
> > >> https://mail.mozilla.org/listinfo/es-discuss
> > >>
> > >>
> > >
> > > _______________________________________________
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> >
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
