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
