Standardizing conditional try/catch

Zach Lym zachlym at indolering.com
Mon Mar 27 22:33:59 UTC 2017


> 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


More information about the es-discuss mailing list