Standardizing conditional try/catch

Isiah Meadows isiahmeadows at gmail.com
Mon Mar 27 22:43:17 UTC 2017


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 <zachlym at indolering.com> wrote:

> > On Sun, Mar 26, 2017 at 10:23 PM, Zach Lym <zachlym at indolering.com>
> 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 <isiahmeadows at gmail.com>
> wrote:
> >>> I want advanced pattern matching, but not something specific to error
> >>> handling.
> >>>
> >>> On Thu, Mar 23, 2017, 06:01 Alexander Jones <alex at weej.com> 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 <isiahmeadows at gmail.com>
> >>>> 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
> >>>>> me at isiahmeadows.com
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <alex at weej.com>
> 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 <kdex at kdex.de> 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 <kdex at kdex.de> 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 <kdex at 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
> >>>>> >> > > > > > > <zachlym at 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 at mozilla.org
> >>>>> >> > > > > > >> https://mail.mozilla.org/listinfo/es-discuss
> >>>>> >> > > > > > >>
> >>>>> >> > > > > > >>
> >>>>> >> > > > > > >
> >>>>> >> > > > > > > _______________________________________________
> >>>>> >> > > > > > > es-discuss mailing list
> >>>>> >> > > > > > > es-discuss at mozilla.org
> >>>>> >> > > > > > > https://mail.mozilla.org/listinfo/es-discuss
> >>>>> >> > > > > > >
> >>>>> >> > > > > > >
> >>>>> >> > > > > >
> >>>>> >> > > > >
> >>>>> >> > > > > _______________________________________________
> >>>>> >> > > > > es-discuss mailing list
> >>>>> >> > > > > es-discuss at mozilla.org
> >>>>> >> > > > > https://mail.mozilla.org/listinfo/es-discuss
> >>>>> >> > > > >
> >>>>> >> > > > >
> >>>>> >> > > >
> >>>>> >> > >
> >>>>> >> > > _______________________________________________
> >>>>> >> > > es-discuss mailing list
> >>>>> >> > > es-discuss at mozilla.org
> >>>>> >> > > https://mail.mozilla.org/listinfo/es-discuss
> >>>>> >> > >
> >>>>> >> > >
> >>>>> >>
> >>>>> >> _______________________________________________
> >>>>> >> es-discuss mailing list
> >>>>> >> es-discuss at mozilla.org
> >>>>> >> https://mail.mozilla.org/listinfo/es-discuss
> >>>>> >>
> >>>>> >
> >>>>> >
> >>>>> > _______________________________________________
> >>>>> > es-discuss mailing list
> >>>>> > es-discuss at mozilla.org
> >>>>> > https://mail.mozilla.org/listinfo/es-discuss
> >>>>> >
> >>>
> >>>
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> es-discuss at mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >
> > -----
> >
> > Isiah Meadows
> > me at isiahmeadows.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170327/c940956b/attachment-0001.html>


More information about the es-discuss mailing list