> 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?
FWIW, this in itself is not a trivial change as it requires extra work
for the debugger.
Thank you,
-Zach Lym
On Sat, Mar 25, 2017 at 6:29 PM, Isiah Meadows <isiahmead...@gmail.com> wrote:
> I want advanced pattern matching, but not something specific to error
> handling.
>
> On Thu, Mar 23, 2017, 06:01 Alexander Jones <a...@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 <isiahmead...@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
>>> m...@isiahmeadows.com
>>>
>>>
>>> On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <a...@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 <k...@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 <k...@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 <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
>>> >> > >
>>> >> > >
>>> >>
>>> >> _______________________________________________
>>> >> 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
