Details of switch with patterns

[gwhitney]

1. I didn't realize until just now that since the generated code just uses PATTERN.test(SUBJECT), a pattern in a switch statement succeeds if SUBJECT merely contains a match to PATTERN, i.e., all of SUBJECT need not match. I think the very first example under Pattern Matching on the Reference page is misleading, because it includes

  /\s+/
    console.log "whitespace"

But (A) down that branch all you know is that the SUBJECT contains a whitespace character (so you might consider changing the code for that case to say console.log "contains whitespace"), not that it "is" whitespace, and (B) unless there is some way of fetching the matching substring in this construct -- and I don't think there is -- then the pattern clause /\s+/ is precisely equivalent to /\s/, so why would you ever use the more complicated /\s+/? I recommend changing to /\s/ in the example.

2. Short of doing

matches := (str,pat) => pat.test(str)
operator matches
mypat := /\s/
switch 'an example subject'
   matches mypat
      console.log "contains whitespace"

there doesn't seem to be a way to re-use a pattern in multiple switches; just mypat in the condition is a parse error and ^mypat tests whether 'an example subject' is === to mypat, which is not helpful. Or am I missing something? Thanks for any thoughts/guidance.

[edemaine]

Regarding 1, I agree. I'd rather suggest /^\s+$/ which was the intent. Are you OK with that change too? I think it clearly communicates the goal, unlike the current example.

Regarding 2: Indeed, that's how it is right now. We still need to add support for arbitrary guards. I could imagine something like the following syntax:

mypat := /\s/
switch 'an example subject'
  .test mypat
    console.log 'contains whitespace'
  // or
  &.test mypat
    console.log 'contains whitespace'

Some more related discussion is in #480. Let us know if you have further suggestions. The meaning of & function blocks seems clear enough, though, so we should probably add that before figuring out how to call arbitrary functions.

A possible workaround for now:

mypat = '\\s'
switch 'an example subject'
  ///${mypat}///
    console.log 'contains whitespace'

...except that switch apparently doesn't support /// regular expression blocks yet. Oops.

[gwhitney]

On (1), I mean sure. That would help. As would an explicit comment "note without the ^ and $, the case would be executed whenever the string contains any whitespace." Whatever you think best, it's your documentation ;-)

On (2), since just a bare word as a case is a parse error, is there a reason not to check if it's (typed as?) a pattern and if so, do pattern matching there? I guess one reason is why favor pattern matching over other forms of case selectors -- although the ^ syntax favors exact equality over other selectors, so it wouldn't be awful to have something that favored pattern matching, too.

The difficulty with your proposed .test mypat selector is that it's NEEDLE.test HAYSTACK, not the other way around. So I guess maybe .match mypat could work, since that has the syntax go the correct direction. But switch doesn't actually support that syntax yet; I think it's proposed in #694.

Finally, /// patterns do work in some cases in switch statements, see #831, which is exactly what I am currently using. However, even though all of

haystack := 'ohfo o'
pat := String.raw`.*o\s+`
console.log /.*o\s+/.test haystack
console.log ///${pat}///.test haystack
switch haystack
   ///.* o \s+///
      console.log 'True that'

work fine, the case selector ///${pat}/// does not compile. (And note that as far as I can tell, you have to use String.raw for pat; when I tried pat := /.*o\s+/ the pattern ///${pat}/// no longer matched 'ohfo o'. But it would be nice if you could interpolate actual regexes into other regexes...)

[gwhitney]

P.S. Incidentally, variable interpolation in ///-regexps does not appear to be documented on the Reference page. I totally understand it's hard to keep docs current with an evolving language -- out of curiosity, is the Reference page generated in some way from (maybe comments in) the source?

[gwhitney]

P.P.S. Not to pile too many slightly disparate things into one discussion (but that's kind of one reason they have a different status than issues, I suppose), but there's never really any reason to use the case selector ^y by itself, as === y means exactly the same thing and is much easier to read. (I realize the pinning ^ has other uses, although somehow it seems to be a bit of a variant of ${}-interpolation...) So with a bare word not compiling and ^y being redundant, it really seems like there ought to be room for a syntax that means "whatever the value of y is, use the selector that would result if y were written out literally here". In fact, I would argue that's exactly how ^ ought to work, by the following rationale. A case selector of 5 means 'SUBJECT === 5'. A case selector of /a/ means /a/.test SUBJECT. If y has the value 5, a case selector of ^y means SUBJECT === 5. But if y has the value /a/, it means SUBJECT === /a/. Why the inconsistency? Either ^y should mean /a/.test SUBJECT when y is /a/, or a case selector of /a/ should mean SUBJECT === /a/. As the latter is not very useful, I conclude the former should be the case.