Proposal-pattern-matching: Reconsidering spelling of `if` and `else`

[mpcsh]

As we discovered in #206, statements like the following have the potential to cause confusion:

match (res) {
  when ({ status: 200 }) { ok(); }
  when ({ status }) if (400 <= status && status < 500) { err(); }
  else { noResponse(); }
}

Specifically, the concern is that folks learning how to use pattern matching will misconstrue the if on the second clause as being attached to the else clause, which would change the mental model of execution here.

Do we have a way to investigate how prevalent this confusion would be? Perhaps using the cognitive dimensions of notation framework that Yulia and Felienne presented last year?

[ljharb]

i think this example isn’t confusing due to the indentation, but it obv could be written in a confusing way:

match (res) {
  when ({ status: 200 }) { ok(); }
  when ({ status })
  if (400 <= status && status < 500) { err(); }
  else { noResponse(); }
}

(and of course, else if would be a syntax error, but that would be quickly discovered if attempted)

[theScottyJam]

Along a similar veign:

match (data) {
  if (1) 'one'
  if (2) 'two'
  else 'other'
}

The second "if" is really behaving as an "else if".

I don't find these issues particularly confusing, and I feel others would quickly get used to them if they do initially find them confusing, but I also see value in exploring other keywords if people want to suggest alternative ideas.

[ljharb]

@theScottyJam true but i don't think we should be concerned whatsoever with someone who's not using any matching, since you'd be able to do this without this proposal (your example would require curly braces on the RHS as well):

do {
  if (data === 1) { 'one' }
  if (data === 2) { 'two' }
  else { 'other' }
}

[maxloh]

How about otherwise?

[fedeci]

@maxloh isn't it a bit verbose?

[theScottyJam]

@ljharb - That was a simplified example (and slightly incorrect example - I see I just put numeric constants in the if instead of comparing it with something). You can throw in a few when (...) ... at the start of that example to make it more complete, and make it so a simple do expression wouldn't replace it.

Either way, it's not a big concern of mine (nor is the original issue) - anyone who understands the rule that "only the first match expression that matches will execute" shouldn't get too tripped up by any of this.

your example would require curly braces on the RHS as well

Aren't you allowed to just put expressions on the RHS side without {}?

[ljharb]

@theScottyJam no, not at the moment. see #181.

[mpcsh]

Reading all this back, I don't see a reasonable way to change the spelling of if. I think else is still the best option for its use; otherwise is alright but a bit verbose. Perhaps it's worth revisiting @tabatkins's proposal of _ in this new light?

EDIT: Speaking of, I was never clear on whether _ would simply replace else, or if it would be used like when _.

[theScottyJam]

I guess there's one way to have an alternative spelling to "if" - in #182 if we go with the idea of taking out the when keyword, then we could change the word if to when, as when would become a free word to use.

For example:

// do this
match (x) {
  ({ a: 1 }) { 2 }
  ({ a: 2, b }) when (!isNaN(b)) { 3 }
  otherwise { 4 }
}

// instead of this
match (x) {
  when ({ a: 1 }) { 2 }
  when ({ a: 2, b }) if (!isNaN(b)) { 3 }
  else { 4 }
}

Just pointing this out, I would rather not do this, but it is an option.

[noppa]

There's bunch of discussion about replacing else with something (I for one don't find otherwise too verbose), but how about replacing if with something else to avoid misunderstandings about where else attaches.
and, for example,

 match (x) {
  when ({ a: 1 }) { 2 }
  when ({ a: 2, b }) and (!isNaN(b)) { 3 }
  else { 4 }
}

[ljharb]

and is likely to be used for chaining matchers (#179).

[waldemarhorwat]

and has the connotation of being commutative, aside from the order of evaluation. It would be really weird for the subexpressions x and y in xandy to use entirely different syntaxes.