Error-Type Specific try/catch Blocks

Isiah Meadows isiahmeadows at gmail.com
Tue May 17 05:48:22 UTC 2016


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 [1]. 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.

[1]: Clojure's `core.match` and equivalents in other Lisps don't count,
since they're macros, not language primitives.

-----

This one has possibly the most detailed response to the idea (you'll have
to start about half way down):

https://esdiscuss.org/topic/extensible-destructuring-proposal

Also, I will note that there's quite a few valid points in this
essay/thread. Not saying this has no chance of making it into the language,
but features do have to pay for their complexity.

https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks

Before I begin the rest of this, keep in mind I *really* want this feature.
I may sound like I don't, but it's that even though I'm aware of the many
large technical limitations and requirements for it to work, I still want
full pattern matching, and I know it's doable.

And pattern matching, even though exceptionally powerful and useful, is
exceptionally complex. If you want it, you'll need to see about getting it
implemented in Sweet and Babel/some other transpiler first.

Async functions got in because of the immediate ubiquity of `co` and other
promise-based coroutines, and it was easy to implement. Generators got in
because lazy iteration was very difficult with several incompatible models,
and coroutines didn't exist, although very sorely needed for async work.
Promises/A+ was incredibly ubiquitous, and the revealing constructor
pattern was increasingly standardized as well, so it was easy to add.

The thing is, pattern matching is up there with generators in terms of
complexity, if not more. For efficient matching, it's even more difficult
when you know so little at runtime. For similar reasons, I won't support
any proposal that relies on proxies, symbols, magic methods, or anything
else that can change at runtime - it's less you have to know, and you can
immediately throw an error when something is misused (like trying to
unapply against an array), much like how engines already make similar
assumptions with typed arrays, often used in performance sensitive code.

To summarize, if you want to get pattern matching into JavaScript, you'll
have to cover many bases and address several fears and concerns, including
avoiding unnecessary comparisons and calls, avoiding unnecessary accesses,
and so on. You'll have to explain how this can be figured out in a single
quick pass for a compiler, because engines don't have time to do complex
work to compile something. Until you can demonstrate that to be doable with
good semantics, and what AST format is best for this (with minimal memory),
it'll be an uphill climb. That's what implementors are concerned about.

As much as I want this feature, I do know of many of the technical
challenges to it.

On Mon, May 16, 2016, 21:26 G. Kay Lee <
balancetraveller+es-discuss at gmail.com> wrote:

> Hmmm, can't find your proposal, mind to share the link directly?
>
> I did however find a comment from Brendan Eich 3 years ago that basically
> resonated with my idea that refutable patterns and matching is the way to
> go for conditional catch, and another thread from a year ago that this
> still is the generally accepted consensus on the topic.
>
> https://esdiscuss.org/topic/conditional-catch-clause
> https://esdiscuss.org/topic/conditional-catch
>
> So I guess this is just yet another highly requested feature that somehow
> ended up in a deadlock then got buried into the deep...
>
>
>
>
> On Tuesday, May 17, 2016, Isiah Meadows <isiahmeadows at gmail.com> wrote:
>
>> Pattern matching has been considered before, and the performance will
>> suck if you consider things like `Point(x, y)`. It's very hard to optimize
>> at runtime, and engines don't have time to optimize that statically.
>>
>> If you want to consider Clojure as an example of one that does this
>> dynamically, it still works ahead of time. The inheritance chain is known
>> statically, and Clojure uses immutable ADTs primarily, so it can do this
>> very quickly.
>>
>> (Spoiler alert: I've tried proposing this myself. It didn't work. You can
>> find previous talk by searching esdiscuss.com via Google.)
>>
>> On Sat, May 14, 2016, 12:17 G. Kay Lee <
>> balancetraveller+es-discuss at gmail.com> wrote:
>>
>>> This is another really far shot - but I'd rather suggest that we should
>>> redefine the role of `case` so that it's no longer just a part of the
>>> `switch` statement but something more generic, as well as introducing a
>>> `match` keyword to enable pattern matching, including the power of matching
>>> by type, so that we can achieve the desired effect in a way illustrated in
>>> the snippets below:
>>>
>>> ```
>>> // plain old switch-case
>>>
>>> switch (expression) {
>>>   case value1:
>>>   case value2:
>>>     ...
>>>     break;
>>>
>>>   default:
>>>     ...
>>> }
>>>
>>> // switch-case with pattern matching; pattern-match by type in this
>>> example
>>>
>>> switch (expression) match {
>>>   case _: boolean
>>>     ...
>>>     break;
>>>
>>>   default:
>>>     ...
>>> }
>>>
>>> // try-catch with pattern matching
>>>
>>> try {
>>>   ...
>>> } catch (error) match {
>>>   case _: TypeError
>>>   case _: SyntaxError
>>>     ...
>>>     break;
>>>
>>>   default:
>>>     ...
>>> }
>>> ```
>>>
>>> Just some rough idea; inspired by Scala syntax.
>>>
>>>
>>>
>>> On Sat, May 14, 2016 at 1:49 AM, Joseph Groseclose <jgrosecl49 at gmail.com
>>> > wrote:
>>>
>>>> I offered a few syntaxes for this, perhaps the bitwise OR "|" would be
>>>> better.
>>>>
>>>> On Fri, May 13, 2016 at 1:33 PM, Michał Wadas <michalwadas at gmail.com>
>>>> wrote:
>>>>
>>>>> > } catch (await FCL.load(...), await FCL.load(...)) (e) {
>>>>> Then you have to override comma operator (
>>>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comma_Operator
>>>>> ) in one specific context...
>>>>>
>>>>> On Fri, May 13, 2016 at 7:14 PM, Joe Groseclose <jgrosecl49 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> @JoePea, that is one of the syntaxes I recommend in the proposal.
>>>>>>
>>>>>> @michalwadas The primary goal of this I think is to create a standard
>>>>>> feature, but I do not see why an expression wrapped in parenthesis
>>>>>> ultimately resulting in an error class would not be supported.
>>>>>>
>>>>>> Example:
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> } catch (await FCL.load(...), await FCL.load(...)) (e) {
>>>>>> ...
>>>>>>
>>>>>> Or something similar for all of the other recommended syntaxes,
>>>>>> replacing the declared class instead with an expression (similar to class
>>>>>> extension).
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> > On May 13, 2016, at 12:54 PM, /#!/JoePea <joe at trusktr.io> wrote:
>>>>>> >
>>>>>> > Perhaps a syntax based on modules:
>>>>>> >
>>>>>> > ```js
>>>>>> > try {}
>>>>>> > catch (TypeError as e) {}
>>>>>> >
>>>>>> > // ...
>>>>>> >
>>>>>> > try {}
>>>>>> > catch (MyError as err) {}
>>>>>> > ```
>>>>>> >
>>>>>> >> On Fri, May 13, 2016 at 9:43 AM, Michał Wadas <
>>>>>> michalwadas at gmail.com> wrote:
>>>>>> >> I can't see why would your syntax be superior to SpiderMonkey
>>>>>> extension
>>>>>> >> except saving few characters.
>>>>>> >>
>>>>>> >> Can your syntax support code like this:
>>>>>> >>
>>>>>> >> async function foo() {
>>>>>> >>   try {
>>>>>> >>      throw new Error();
>>>>>> >>   } catch(e if isNativeException(e)) {
>>>>>> >>     // special handler for DOM exceptions
>>>>>> >>   } catch(e if e instanceof (await
>>>>>> >> fancyClassLoader.load('classes/SomeLibrary/UserDefinedError'))) {
>>>>>> >>      // load class asynchronously if it wasn't loaded
>>>>>> >>   }
>>>>>> >> }
>>>>>> >>
>>>>>> >> ?
>>>>>> >>
>>>>>> >>
>>>>>> >> On Fri, May 13, 2016 at 5:58 PM, Joseph Groseclose <
>>>>>> jgrosecl49 at gmail.com>
>>>>>> >> wrote:
>>>>>> >>>
>>>>>> >>> I've updated the proposal. See:
>>>>>> >>>
>>>>>> https://github.com/benderTheCrime/error-type-specific-catch-proposal#about-spidermonkey-implementation
>>>>>> >>>
>>>>>> >>> On Fri, May 13, 2016 at 11:49 AM, Joseph Groseclose <
>>>>>> jgrosecl49 at gmail.com>
>>>>>> >>> wrote:
>>>>>> >>>>
>>>>>> >>>> Nevertheless, perhaps the non-standard implementation could work
>>>>>> >>>> hand-in-hand with the proposal, where SpiderMonkey could support
>>>>>> both
>>>>>> >>>> solutions in parallel for backward compatibility. I think that
>>>>>> the proposed
>>>>>> >>>> solution is more expressive.
>>>>>> >>>>
>>>>>> >>>> On Fri, May 13, 2016 at 11:26 AM, Claude Pache <
>>>>>> claude.pache at gmail.com>
>>>>>> >>>> wrote:
>>>>>> >>>>>
>>>>>> >>>>> Note that SpiderMonkey has already nonstandard conditional catch
>>>>>> >>>>> clauses:
>>>>>> >>>>>
>>>>>> >>>>> ```js
>>>>>> >>>>> try {
>>>>>> >>>>>    // ...
>>>>>> >>>>> }
>>>>>> >>>>> catch (e if e instanceof TypeError) {
>>>>>> >>>>>    // ....
>>>>>> >>>>> }
>>>>>> >>>>> ```
>>>>>> >>>>>
>>>>>> >>>>> —Claude
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> Le 13 mai 2016 à 17:06, Joseph Groseclose <jgrosecl49 at gmail.com>
>>>>>> a écrit
>>>>>> >>>>> :
>>>>>> >>>>>
>>>>>> >>>>> I sent this proposal via
>>>>>> >>>>>
>>>>>> http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php#
>>>>>> >>>>> yesterday evening. Sharing it here now:
>>>>>> >>>>>
>>>>>> https://github.com/benderTheCrime/error-type-specific-catch-proposal
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> _______________________________________________
>>>>>> >>>>> es-discuss mailing list
>>>>>> >>>>> es-discuss at mozilla.org
>>>>>> >>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> _______________________________________________
>>>>>> >>> es-discuss mailing list
>>>>>> >>> es-discuss at mozilla.org
>>>>>> >>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >>
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> es-discuss mailing list
>>>>>> >> es-discuss at mozilla.org
>>>>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160517/949c3f6c/attachment-0001.html>


More information about the es-discuss mailing list