Proposed simplification & increased symmetry

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.

@tabatkins

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.

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.

@erights

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

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!

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

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.

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.

@codehag

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.

@codehag

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?

@erights

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.

@codehag

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

@ljharb

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.

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!

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.

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

I'm sorry to keep repeating this, but can you share one of these examples?

The thing that really worries me is this rule:

CoverCallExpressionAndAsyncArrowHead[?Yield, ?Await] [no LineTerminator here] { MatchExpressionClauses[?Yield, ?Await] ; }

This will work once, but the juxtaposition of the cover grammar with the match syntax will preclude all future attempts to introduce new syntax consisting of the form keyword (expr) {block}.

We've gotten ourselves into a corner.

The current proposal's spec text can be adapted any way needed. I agree that we need to ensure that that form can be added in the future, as well as that new unreserved binary keywords can be added, and any proposal that would disrupt that should not advance until the problem has been resolved.

@ljharb

@ljharb: Example: let is. This one can be fixed with more line break restrictions, but there are others I'm working on constructing which can't.

It sounds like we would need to rethink some of the cover grammars, not abandon infix keywords.

We can have either prefix non-reserved keywords or infix non-reserved keywords. They're generally mutually exclusive. Given a blank slate, we could have decided on one or the other, but we don't have a blank slate. We already have prefix non-reserved keywords to introduce various things in the language and some more in proposals in the pipeline. Trying to introduce infix non-reserved keywords would create problems for prefix non-reserved keywords.

Proposals in the pipeline. pre-stage 3, can (and should) be changed if they're closing off design space. What are the ones in the language? (you mentioned let, so presumably var and const, but i'm not sure why that precludes new keywords?)

Proposals closing off the design space include things like explicit resource management, which is in stage 3, as well as a bunch of things already in the language. But the patterns proposal's current form would close off more of the design space than any of those — see my comment about the match syntax above. If we're worried about closing off the design space (and I am), we should fix the syntax of the patterns proposal to not use keywords usable as identifiers to mark patterns. Things like ~= are one of the options to preserve the design space.

Can you provide a list of the things already in the language?

Making that list would be an important effort. Finding them all would require computer validation of the grammar, including cover grammars. I wrote such a thing for an earlier version of ECMAScript, but it would take me a while to bring it up to date.

@ljharb

at the least, hopefully we can agree that having "renaming properties" and "renaming imports" be different was a mistake - it consumes double the syntax space for the same conceptual operation.

@ljharb I can't remember who said that, but it is said destructuring is assignment but import is aliasing so they use different syntax to denote semantic difference. Though I can't tell whether I agree or not.

FWIW, if destructuring used as, we'd probably be able to write:

const sayHello = ({
  to as name: string
}) => { ... }

instead of:

const sayHello = ({
  to: name
}: {
  to: string
}) => { ... }

But of course it's too late. :/

I agree that it would be better to restore the symmetry with destructuring with respect to when/how bindings are introduced.

Pattern matching cannot have symmetry with all existing syntax in the language, and already breaks symmetry with destructuring semantics due to array exhaustiveness. Introducing symmetry with bindings breaks symmetry with identifier references and makes the syntax even more complicated. We introduced let/const bindings to address other concerns about making the bindings visible, and they carry along with them many other benefits when combined with is.

We must break symmetry somewhere, and breaking symmetry with bindings addressed other concerns.

Regarding ~=, there is a lot of inconsistent prior art in the field (e.g., Bash and Perl and Ruby use =~, and Python package version matching and Swift use ~= [but the latter ordered like $pattern ~= $specimen], while AWK and nginx and PostgreSQL use ~ [and the latter two also use ~* for case insensitivity] and Lua uses ~= for "not equals")—and I personally am stymied just about every time I try to use any of them.

If we were to handle this by punctuation, it might be worth considering something more distinctive that in particular does not break the pattern where 𝒙= means "apply 𝒙 and assign back" when 𝒙 is an operator (although currently limited to binary operators). Maybe ~==, although I don't love that either.

Navigation Menu

Repository navigation

Proposed simplification & increased symmetry #322

A.1 Expressions

23 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Proposed simplification & increased symmetry #322

Description

A.1 Expressions

Activity

erights commented on Apr 9, 2024

Jack-Works commented on Apr 9, 2024

ljharb commented on Apr 9, 2024

erights commented on Apr 9, 2024

Jack-Works commented on Apr 9, 2024

erights commented on Apr 9, 2024

ljharb commented on Apr 9, 2024

erights commented on Apr 9, 2024

erights commented on Apr 9, 2024

codehag commented on Apr 9, 2024

ljharb commented on Apr 9, 2024

codehag commented on Apr 9, 2024

erights commented on Apr 9, 2024

erights commented on Apr 9, 2024

ljharb commented on Apr 9, 2024

23 remaining items

ljharb commented on Apr 10, 2024

waldemarhorwat commented on Apr 10, 2024

ljharb commented on Apr 10, 2024

waldemarhorwat commented on Apr 10, 2024

rbuckton commented on Apr 10, 2024

waldemarhorwat commented on Apr 10, 2024

ljharb commented on Apr 10, 2024

waldemarhorwat commented on Apr 10, 2024

ljharb commented on Apr 10, 2024

waldemarhorwat commented on Apr 10, 2024

hax commented on Apr 10, 2024

gustavopch commented on Apr 10, 2024

littledan commented on Apr 11, 2024

rbuckton commented on Apr 11, 2024

gibson042 commented on Apr 11, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions