Standardizing conditional try/catch

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 - [hidden email] - 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" <[hidden email]> 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 <[hidden email]> 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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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 <[hidden email]> 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
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

T.J. Crowder-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

Michał Wadas
In reply to this post by kdex

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 <[hidden email]> 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 <[hidden email]> 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
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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 <[hidden email]>
> > 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
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > > > _______________________________________________
> > > > es-discuss mailing list
> > > > [hidden email]
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

Michael J. Ryan
In reply to this post by T.J. Crowder-2
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 - [hidden email] - 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

Michael J. Ryan
In reply to this post by kdex
Along a similar vein, is it time to discuss optional typing a la flow/typescript which seem to be going a very similar direction with different tooling?

Though I'm really unsure about the need/bloat beyond tooling and kind of feel that generic expression support for catch blocks may be enough.

--
Michael J. Ryan - [hidden email] - http://tracker1.info

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

On Mar 19, 2017 8:24 AM, "kdex" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > > > _______________________________________________
> > > > es-discuss mailing list
> > > > [hidden email]
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

Zach Lym
In reply to this post by kdex
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > > > _______________________________________________
> > > > es-discuss mailing list
> > > > [hidden email]
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > > 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
> > > > > >> [hidden email]
> > > > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > _______________________________________________
> > > > > > es-discuss mailing list
> > > > > > [hidden email]
> > > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > es-discuss mailing list
> > > > [hidden email]
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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


On Sun, Mar 19, 2017 at 3:47 PM, kdex <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > > 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
> > > > > >> [hidden email]
> > > > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > _______________________________________________
> > > > > > es-discuss mailing list
> > > > > > [hidden email]
> > > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > es-discuss mailing list
> > > > [hidden email]
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

Alexander Jones
In reply to this post by kdex
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > > 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
> > > > > >> [hidden email]
> > > > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > _______________________________________________
> > > > > > es-discuss mailing list
> > > > > > [hidden email]
> > > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > es-discuss mailing list
> > > > [hidden email]
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

Isiah Meadows-2
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
[hidden email]


On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> > > > > > > <[hidden email]>
>> > > > > 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
>> > > > > > >> [hidden email]
>> > > > > > >> https://mail.mozilla.org/listinfo/es-discuss
>> > > > > > >>
>> > > > > > >>
>> > > > > > >
>> > > > > > > _______________________________________________
>> > > > > > > es-discuss mailing list
>> > > > > > > [hidden email]
>> > > > > > > https://mail.mozilla.org/listinfo/es-discuss
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > es-discuss mailing list
>> > > > > [hidden email]
>> > > > > https://mail.mozilla.org/listinfo/es-discuss
>> > > > >
>> > > > >
>> > > >
>> > >
>> > > _______________________________________________
>> > > es-discuss mailing list
>> > > [hidden email]
>> > > https://mail.mozilla.org/listinfo/es-discuss
>> > >
>> > >
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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
[hidden email]


On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> > > > > > > <[hidden email]>
>> > > > > 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
>> > > > > > >> [hidden email]
>> > > > > > >> https://mail.mozilla.org/listinfo/es-discuss
>> > > > > > >>
>> > > > > > >>
>> > > > > > >
>> > > > > > > _______________________________________________
>> > > > > > > es-discuss mailing list
>> > > > > > > [hidden email]
>> > > > > > > https://mail.mozilla.org/listinfo/es-discuss
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > es-discuss mailing list
>> > > > > [hidden email]
>> > > > > https://mail.mozilla.org/listinfo/es-discuss
>> > > > >
>> > > > >
>> > > >
>> > >
>> > > _______________________________________________
>> > > es-discuss mailing list
>> > > [hidden email]
>> > > https://mail.mozilla.org/listinfo/es-discuss
>> > >
>> > >
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

Isiah Meadows-2
I want advanced pattern matching, but not something specific to error handling.

On Thu, Mar 23, 2017, 06:01 Alexander Jones <[hidden email]> 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 <[hidden email]> 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
[hidden email]


On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> > > > > > > <[hidden email]>
>> > > > > 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
>> > > > > > >> [hidden email]
>> > > > > > >> https://mail.mozilla.org/listinfo/es-discuss
>> > > > > > >>
>> > > > > > >>
>> > > > > > >
>> > > > > > > _______________________________________________
>> > > > > > > es-discuss mailing list
>> > > > > > > [hidden email]
>> > > > > > > https://mail.mozilla.org/listinfo/es-discuss
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > es-discuss mailing list
>> > > > > [hidden email]
>> > > > > https://mail.mozilla.org/listinfo/es-discuss
>> > > > >
>> > > > >
>> > > >
>> > >
>> > > _______________________________________________
>> > > es-discuss mailing list
>> > > [hidden email]
>> > > https://mail.mozilla.org/listinfo/es-discuss
>> > >
>> > >
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> wrote:

> I want advanced pattern matching, but not something specific to error
> handling.
>
> On Thu, Mar 23, 2017, 06:01 Alexander Jones <[hidden email]> 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 <[hidden email]>
>> 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
>>> [hidden email]
>>>
>>>
>>> On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> >> > > > > > > <[hidden email]>
>>> >> > > > > 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
>>> >> > > > > > >> [hidden email]
>>> >> > > > > > >> https://mail.mozilla.org/listinfo/es-discuss
>>> >> > > > > > >>
>>> >> > > > > > >>
>>> >> > > > > > >
>>> >> > > > > > > _______________________________________________
>>> >> > > > > > > es-discuss mailing list
>>> >> > > > > > > [hidden email]
>>> >> > > > > > > https://mail.mozilla.org/listinfo/es-discuss
>>> >> > > > > > >
>>> >> > > > > > >
>>> >> > > > > >
>>> >> > > > >
>>> >> > > > > _______________________________________________
>>> >> > > > > es-discuss mailing list
>>> >> > > > > [hidden email]
>>> >> > > > > https://mail.mozilla.org/listinfo/es-discuss
>>> >> > > > >
>>> >> > > > >
>>> >> > > >
>>> >> > >
>>> >> > > _______________________________________________
>>> >> > > es-discuss mailing list
>>> >> > > [hidden email]
>>> >> > > https://mail.mozilla.org/listinfo/es-discuss
>>> >> > >
>>> >> > >
>>> >>
>>> >> _______________________________________________
>>> >> es-discuss mailing list
>>> >> [hidden email]
>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > [hidden email]
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

Isiah Meadows-2
Inline


On Sun, Mar 26, 2017 at 10:23 PM, Zach Lym <[hidden email]> 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 <[hidden email]> wrote:
>> I want advanced pattern matching, but not something specific to error
>> handling.
>>
>> On Thu, Mar 23, 2017, 06:01 Alexander Jones <[hidden email]> 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 <[hidden email]>
>>> 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
>>>> [hidden email]
>>>>
>>>>
>>>> On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> >> > > > > > > <[hidden email]>
>>>> >> > > > > 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
>>>> >> > > > > > >> [hidden email]
>>>> >> > > > > > >> https://mail.mozilla.org/listinfo/es-discuss
>>>> >> > > > > > >>
>>>> >> > > > > > >>
>>>> >> > > > > > >
>>>> >> > > > > > > _______________________________________________
>>>> >> > > > > > > es-discuss mailing list
>>>> >> > > > > > > [hidden email]
>>>> >> > > > > > > https://mail.mozilla.org/listinfo/es-discuss
>>>> >> > > > > > >
>>>> >> > > > > > >
>>>> >> > > > > >
>>>> >> > > > >
>>>> >> > > > > _______________________________________________
>>>> >> > > > > es-discuss mailing list
>>>> >> > > > > [hidden email]
>>>> >> > > > > https://mail.mozilla.org/listinfo/es-discuss
>>>> >> > > > >
>>>> >> > > > >
>>>> >> > > >
>>>> >> > >
>>>> >> > > _______________________________________________
>>>> >> > > es-discuss mailing list
>>>> >> > > [hidden email]
>>>> >> > > https://mail.mozilla.org/listinfo/es-discuss
>>>> >> > >
>>>> >> > >
>>>> >>
>>>> >> _______________________________________________
>>>> >> es-discuss mailing list
>>>> >> [hidden email]
>>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > es-discuss mailing list
>>>> > [hidden email]
>>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>> >
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>

-----

Isiah Meadows
[hidden email]
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standardizing conditional try/catch

Zach Lym
> On Sun, Mar 26, 2017 at 10:23 PM, Zach Lym <[hidden email]> 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 <[hidden email]> wrote:
>>> I want advanced pattern matching, but not something specific to error
>>> handling.
>>>
>>> On Thu, Mar 23, 2017, 06:01 Alexander Jones <[hidden email]> 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 <[hidden email]>
>>>> 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
>>>>> [hidden email]
>>>>>
>>>>>
>>>>> On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>> >> > > > > > > <[hidden email]>
>>>>> >> > > > > 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
>>>>> >> > > > > > >> [hidden email]
>>>>> >> > > > > > >> https://mail.mozilla.org/listinfo/es-discuss
>>>>> >> > > > > > >>
>>>>> >> > > > > > >>
>>>>> >> > > > > > >
>>>>> >> > > > > > > _______________________________________________
>>>>> >> > > > > > > es-discuss mailing list
>>>>> >> > > > > > > [hidden email]
>>>>> >> > > > > > > https://mail.mozilla.org/listinfo/es-discuss
>>>>> >> > > > > > >
>>>>> >> > > > > > >
>>>>> >> > > > > >
>>>>> >> > > > >
>>>>> >> > > > > _______________________________________________
>>>>> >> > > > > es-discuss mailing list
>>>>> >> > > > > [hidden email]
>>>>> >> > > > > https://mail.mozilla.org/listinfo/es-discuss
>>>>> >> > > > >
>>>>> >> > > > >
>>>>> >> > > >
>>>>> >> > >
>>>>> >> > > _______________________________________________
>>>>> >> > > es-discuss mailing list
>>>>> >> > > [hidden email]
>>>>> >> > > https://mail.mozilla.org/listinfo/es-discuss
>>>>> >> > >
>>>>> >> > >
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> es-discuss mailing list
>>>>> >> [hidden email]
>>>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>>>> >>
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > es-discuss mailing list
>>>>> > [hidden email]
>>>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>>> >
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>
> -----
>
> Isiah Meadows
> [hidden email]
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12
Loading...