Re: Standardizing conditional try/catch

[Isiah Meadows]

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  wrote:

> > On Sun, Mar 26, 2017 at 10:23 PM, Zach Lym 
> 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 
> wrote:
> >>> I want advanced pattern matching, but not something specific to error
> >>> handling.
> >>>
> >>> On Thu, Mar 23, 2017, 06:01 Alexander Jones  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 
>  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 
> 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  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  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

Re: Standardizing conditional try/catch

[Zach Lym]

> On Sun, Mar 26, 2017 at 10:23 PM, Zach Lym  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  
>> wrote:
>>> I want advanced pattern matching, but not something specific to error
>>> handling.
>>>
>>> On Thu, Mar 23, 2017, 06:01 Alexander Jones  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 
 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  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  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  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 

Re: Standardizing conditional try/catch

[Isiah Meadows]

Inline


On Sun, Mar 26, 2017 at 10:23 PM, Zach Lym  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.

>
> FWIW, this in itself is not a trivial change as it requires extra work
> for the debugger.

I get that it'd be difficult for the debugger to handle.

>
>
> Thank you,
> -Zach Lym
>
>
> On Sat, Mar 25, 2017 at 6:29 PM, Isiah Meadows  wrote:
>> I want advanced pattern matching, but not something specific to error
>> handling.
>>
>> On Thu, Mar 23, 2017, 06:01 Alexander Jones  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 
>>> 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  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  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  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 

Re: Standardizing conditional try/catch

[Zach Lym]

> 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  wrote:
> I want advanced pattern matching, but not something specific to error
> handling.
>
> On Thu, Mar 23, 2017, 06:01 Alexander Jones  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 
>> 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  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  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  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  wrote:
>>> >> > > >
>>> >> > > > > I'm not sure if embedding this idea into the language will
>>> >> > > > > make
>>> >> > > > > future
>>> >> > > > > ideas about true pattern matching harder to 

Re: Standardizing conditional try/catch

[Isiah Meadows]

I want advanced pattern matching, but not something specific to error
handling.

On Thu, Mar 23, 2017, 06:01 Alexander Jones  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  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  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  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  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  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
>> > > > > > > 
>> > > > > wrote:
>> > > > > > >
>> > > > > > >> Firefox supports the following conditional `catch` syntax:
>> > > > > > >>
>> > > > > > >> try {
>> > > > > > >>

Re: Standardizing conditional try/catch

[Alexander Jones]

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  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  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  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  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  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
> >> > > > > > > 
> >> > > > > wrote:
> >> > > > > > >
> >> > > > > > >> Firefox supports the following 

Re: Standardizing conditional try/catch

[Isiah Meadows]

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  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  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  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  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
>> > > > > > > 
>> > > > > 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 

Re: Standardizing conditional try/catch

[Alexander Jones]

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  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  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  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 

Re: Standardizing conditional try/catch

[Zach Lym]

> Why not start speccing out some details for an optional typing proposal
instead, so we can get the ball rolling for true pattern matching?

Every serious typing proposals has flatlined [0] and pattern matching
requires consensus on deep changes to JS that are very contentious [1]:

> TL;DR: I really want full pattern matching, but it's a very long and
steep road to climb, and no one has gotten it right yet in a dynamic
language. None of the implementors will be okay with it until you
demonstrate that it's both possible and practical to implement, with
minimal memory and time overhead. It has to work as fast as traditional
conditionals for anything beyond unapplying. It cannot slow down parsing or
compilation more than marginally. It has to also satisfy the community and
its needs.

I don't want to wait another decade for JS to have a clean async
programming syntax.

Besides, what does the match syntax really get you in this case?  Match is
useful for dispatching single function calls and making converting long
chains of horizontal if statements into vertical ones.  It's not a general
purpose replacement for if/else blocks.

Thank you,
-Zach Lym

[0]: https://github.com/tc39/ecma262/issues/45#issuecomment-202033608
[1]: https://esdiscuss.org/topic/error-type-specific-try-
catch-blocks#content-14

On Sun, Mar 19, 2017 at 3:47 PM, kdex  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  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  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
> 

Re: Standardizing conditional try/catch

[kdex]

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  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  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 
> > > > 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]: 

Re: Standardizing conditional try/catch

[Zach Lym]

>
> 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  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  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 
> > > 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
> > > 

Re: Standardizing conditional try/catch

[Michael J. Ryan]

Could also do like C# does and treat just `throw;` as an explicit rethrow...

 I'm also not sure a lot of optimizations are needed as this is exception
handling as otherwise mentioned.


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Mar 18, 2017 12:21 PM, "T.J. Crowder" 
wrote:

> I don't see optimization being a big deal, this is exception processing
> after all.
>
> I was also thinking any expression:
>
> ```js
> try {
> // ...
> }
> catch (e if arbitraryExpression1Here) {
> // ...handle case 1
> }
> catch (e if arbitraryExpression2Here) {
> // ...handle case 2
> }
> ```
>
> ...which would essentially be:
>
> ```js
> try {
> // ...
> }
> catch (e) {
> if (arbitraryExpression1Here) {
> // ...handle case 1
> } else if (arbitraryExpression2Here) {
> // ...handle case 2
> } else {
> throw e;
> }
> }
> ```
>
> ...but without messing up the reported source of the error/stack (I'm
> looking at you, IE11).
>
> -- T.J. Crowder
>
>
> On Sat, Mar 18, 2017 at 6:06 PM, Jordan Harband  wrote:
>
>> If the condition can be just "any javascript", wouldn't that potentially
>> impede optimizations? Hopefully implementors can weigh in here, since
>> non-implementor performance intuition (like mine) is often off base.
>>
>> On Sat, Mar 18, 2017 at 9:16 AM, kdex  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 
>>> 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
> 

Re: Standardizing conditional try/catch

[kdex]

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  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 
> > 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
> >
> >
> 

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing conditional try/catch

[Jordan Harband]

If the condition can be just "any javascript", wouldn't that potentially
impede optimizations? Hopefully implementors can weigh in here, since
non-implementor performance intuition (like mine) is often off base.

On Sat, Mar 18, 2017 at 9:16 AM, kdex  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 
> 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

Re: Standardizing conditional try/catch

[kdex]

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  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
> >
> >
> 

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing conditional try/catch

[Michael J. Ryan]

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...

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Mar 17, 2017 11:29 PM, "Jordan Harband"  wrote:

> `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  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

Re: Standardizing conditional try/catch

[Jordan Harband]

`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  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-
> blocks#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

Standardizing conditional try/catch

[Zach Lym]

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-blocks#content-14
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss