Proposed simplification & increased symmetry

[erights]

Playing a little fast and loose with the metagrammar, I think this proposal should be simplified to

A.1 Expressions

• PrimaryExpr:

  • //... existing stuff
  • MatchExpr // Like in proposal

• RelationalExpr: // unchanged, but useful below

  • //... existing stuff
  • RelationalExpr ( < | <= | >= | > ) ShiftExpr
  • RelationalExpr ( instanceof | in ) ShiftExpr

• EqualityExpr:

  • //... existing stuff
  • EqualityExpr ( == | != | === | !== ) RelationalExpr
  • EqualityExpr ~= MatchPattern // like the proposed is

• MatchPattern:

  • // Like in proposal and like destructuring
    • void // I'm a fan, and allows ...void
    • MatchPattern = AssignmentExpr // can we make defaults this simple?
    • [ (MatchPattern,)* (...MatchPattern)? ]
    • { (Prop: MatchPattern,)* (...MatchPattern)? }
    • Extractor
  • // Nice-to-have, unless Extractors can subsume these?
    • MatchPattern and MatchPattern // consider && ?
    • MatchPattern or MatchPattern // consider || ?
    • not MatchPattern // consider ! ?
    • if ( Expr )
  • // Different!
    • Identifier // Binding occurrence, like destructuring
    • ( < | <= | >= | > ) ShiftExpr
    • ( === | !== ) RelationalExpr
    • ~= MatchPattern

• Left-Hand-Side Exprs: // enhance destructuring

  • //... existing stuff
  • void
  • Extractor // refutable
  • ~= MatchPattern // refutable
  • // How much more from MatchPattern could we add here?

---

The main change is how the distinction between comparing against values is expressed vs how bindings are introduced. The existing proposal treats a bare Identifier as a lexical reference to a variable from the enclosing scope, so it introduces bindings with a let, const, or var prefix. This is not at all like destructuring. IMO people will be confused by this asymmetry.

I saw in the proposal a suggestion of a pattern to be able to start with a (normally binary) relational operator followed by an expression. This is the opportunity to restore the symmetry with destructuring! This gives a way to introduce expressions whose value can be compared, including expressions using variables from outer scopes. Any Identifier appearing normally in a pattern is binding occurrence, just as one expects from destructuring.

[erights]

Separately, I agree with @tabatkins that the when should be dropped. I find the argument from indentation + ; convincing. But here I focus on the pattern side.

[Jack-Works]

We used to make Identifier a binding, but that approach is considered harmful. You can see history discussion at #281

EqualityExpr ~= MatchPattern

I'm unsure why ~= is better than is. We don't have many symbols left so I prefer is.

void and ...void

It will be added by https://github.com/tc39/proposal-discard-binding. If that proposal succeeds, apparently ...void will also be valid.

MatchPattern = AssignmentExpr

We haven't seriously considered this yet, but we have an editor note in the spec "It is possible to add Initializer to MatchProperty and MatchElement."

consider && and ||

We've discussed that in the past, see #179

consider !

not is a natural choice after we use and and or.

[ljharb]

@erights i'm a bit confused about what your OP is proposing. Are you suggesting we flip back to "idenfitiers are irrefutable patterns", and use a sigil to mark bindings, as opposed to let/const?

[erights]

On Mon, Apr 8, 2024 at 8:14 PM Jack Works ***@***.***> wrote: We used to make Identifier a binding, but that approach is considered harmful. You can see history discussion at #281 <#281>

That is a huge thread! Where should I look? Our could you summarize? This issue of bare identifiers is my biggest concern, so clarification appreciated. Thanks!

[Jack-Works]

That is a huge thread! Where should I look? Or could you summarize?

The core problem is readability. You can see Yulia's analysis of the old syntax https://docs.google.com/document/d/1dVaSGokKneIT3eDM41Uk67SyWtuLlTWcaJvOxsBX2i0/edit

[erights]

On Mon, Apr 8, 2024 at 8:23 PM Jordan Harband ***@***.***> wrote: @erights <https://github.com/erights> i'm a bit confused about what your OP is proposing. Are you suggesting we flip back to "idenfitiers are irrefutable patterns",

Yes

and use a sigil to mark bindings, as opposed to let/const?

Not to mark bindings. Bare identifiers are bindings. ===expr uses === to mark an expression, including a normal variable name use occurrence. And without privileging === over other relational operators.

[ljharb]

If I understand properly, that was our original proposal - and yulia and the firefox team blocked it. The change to using let/const was to unblock the proposal.

[erights]

That is a huge thread! Where should I look? Or could you summarize?

The core problem is readability. You can see Yulia's analysis of the old syntax https://docs.google.com/document/d/1dVaSGokKneIT3eDM41Uk67SyWtuLlTWcaJvOxsBX2i0/edit

Thanks. Looked, but without having followed the history I'm having a hard time understanding this doc. Since I do understand the current proposal, which IIUC meets @codehag 's objections, could you write one of these examples using the current state of this proposal. Or any example that should illustrate the disadvantage of my suggestion. I'll then try to rewrite in terms of my suggestion and we can compare.

[erights]

Hi @codehag !

I think we have aligned notions of programmer cognitive costs, so I'm curious if we actually arrive at opposite conclusions. Do you support the current proposal over my suggestion? Could you show a maximally challenging example written in the current proposal, for me to rewrite in my suggestion?

[codehag]

Regarding that document, my purpose was not to use necessarily let or const, but rather to make it clear that a binding was taking place for the user, in a way that was more obvious. Aliasing in my opinion is an antipattern as it overrides notions that the programmer has about assignment: We should have instead added an as keyword or similar. But this is history.

After discussion with the champions, I was dismayed but convinced that we could reuse aliasing. Since it is being used in Extractors, if that advances I think it will be clear how we should advance here. My understanding in the calls was that the champions had their own reasons for having let/const. This was over a year ago. If it is only for my sake that we have let/const, it should be removed. It is clear that the tendency in the language goes a different way.

Do you support the current proposal over my suggestion? Could you show a maximally challenging example written in the current proposal, for me to rewrite in my suggestion?

The proposal authors have done a great job in trying to respond to my comments. My core concern was that the proposal is too complex, which they fundamentally disagree with. This was also what my proposed breakdown tried to do. We've moved quite far since there, but my core concern still applies. I think we should start with a simpler approach. In fact, I think that we can get very far in terms of pattern matching with extractors (it fulfills my concept of a base proposal, but this is a separate topic).

I am not sure how to communicate this. I support pattern matching in the language, and a lot of the work has been really great here. But my concern was not addressed. Not only for implementation concerns, but for usability and also to allow us to correct ourselves over time. The blocking concern, when I made it, was complexity -- not any particular syntax. Unfortunately, I think my attempt in being precise about my concerns resulted in the proposal becoming more complex, which wasn't my intention.

Of course, I also have personal thoughts here. In particular, we should take time with the pattern matching language -- what @erights are proposing changing in the second half of your post iiuc. We have a potential to do something really great with this, I'd like to see it fully fleshed out. It could be treated like RegExp. Another area I disagreed with the champions is that this needs to be tied to a match statement. But it doesn't look like this is the direction things are going and I don't have much time now to help with the design. So I will set these thoughts aside rather than get in the way of those who are doing the work.

Regarding your suggestions, I think there are potential benefits, such as a closer relationship to existing syntax, and also drawbacks, such as searchability being generally worse for operators. Again, would love to see a deep investigation of a language for structural matching, without any concerns regarding the match statement.

Overall, I support simplification.

[ljharb]

@codehag fwiw in the current proposal the pattern DSL is not tied only to the match statement; there's also the is operator, and a lot of follow-on proposals planned.

[codehag]

Apologies! I am not up to date. I saw the proposal recently and I was still unsure about the level of complexity, but again, not planning on getting in the way here. I'd like to see a simple subset land first and build from that, but @ljharb you and I have had a call about this and we both know where we stand :). I won't rehash it.

[erights]

My sense is that destructuring + extractors is almost all of what I want from pattern matching itself. Just for pattern matching, the only deficiencies I see with destructuring + extractors alone:

• irrefutable destructuring. In retrospect I think this was a mistake. The pattern proposal for refutable array and object patterns is what we should have done for destructuring. But given that mistake, I'm torn about whether to introduce the non-uniformity of also having refutable array and object patterns into the same language. If we don't make these different, then perhaps we don't need a distinct notion of "pattern" and can just enhance destructuring with extractors and the small number of additional things we'd want for patterns; like the next two bullets.
• void (from a separate proposal) just makes destructuring and pattern matching better.
• no way to parameterize the extractor or pattern inline with data. I cannot think of tolerable a way to parameterize an extractor. But inserting tests against computed data with ===expr (and other relops) addresses the main pain point adequately.

How well could we write the equivalent of and, or, or not using extractors? If adequately well, I'd prefer to omit these from the grammar. But let's see what it looks like.

Other less urgent elements which I think I still favor, but probably could be talked out of. They could at least be postponed:

• Since extractors are refutable even within destructuring, destructing + extractors become usefully refutable. From experience in E, adding a relational-like operation like expr ~= pattern (where ~= is a rename of is and pattern may be this generalized destructuring) seems to add significant value.
• Given such a relational-like op, I'd even favor something like the proposed scoping rules when the ~= expression is in an if head. Though I'd have the scope cover only the then-part, not the else-part. Also while and all fors, but not do ... while. The scope is only for code executed when the pattern succeeds.

But, no matter whether we generalize destructuring to become useful as refutable patterns or we introduce a pattern notion distinct from destructuring, I think we will need something like the proposed match expression, for which the proposal itself is a fine place to start. OTOH, if we have ~= with the above scoping rules, then

match (specimen) {
  patt1: action1;
  patt2: action2;
  default: action3;
}

is much like

if (specimen ~= patt1) {
  action1
} else if (specimen ~= patt2) {
  action2
} else {
  action3
}

or even, for the expression case

specimen ~= patt1 ? action1 
  : specimen ~= patt2 ? action2
  : action3

The repetition of specimen need not be more painful that introducing a short variable name for purposes of repetition, if necessary. On reflection, I'd agree that it is not worth introducing the whole match syntax family merely to avoid the pain of repeating the specimen.

So, I favor enhanced destructuring centered on extractors, together with some of these additional enhancements. Perhaps we don't need a distinct notion of patterns or special match syntax. My main regret would only be that the array and object destructuring is too irrefutable. This by itself still may be sufficient to want a distinct notion of "pattern".

---

I would still love to examine all this against motivating challenge examples. Please someone, fire away!

[erights]

Ah. Because we cannot parameterize an extractor inline, we cannot write extractor combinators as extractors, if we want the combinator expression inline, which we do. Sigh.

[ljharb]

I definitely agree that object destructuring has a few mistakes in it, in particular using : instead of as for renaming.