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