search: simplify case statement

[rvantonder]

stacked on #37657

Test plan

semantics-preserving

[sourcegraph-bot]

Codenotify: Notifying subscribers in CODENOTIFY files for diff 4f2c999...683eb80.

Notify	File(s)
@beyang	internal/search/query/query.go
@camdencheek	internal/search/query/query.go
@keegancsmith	internal/search/query/query.go

[camdencheek]

Trying to make sure I undestand this. Please tell me if any of these statements are inaccurate:

• All of the below are true for SearchTypeStandard
• We can have literal patterns and /regex patterns/
• Space-separated literal patterns will be parsed into Concat nodes
• /regex patterns/ will be parsed as a single pattern node with the Standard label set
• /regex patterns/ will never exist in a concat node
• We can safely join concat nodes with spaces because /regex patterns/ will not exist in a concat node

[rvantonder]

Good question, so the end state behavior isn't implemented yet, I'm just organizing this. I need to implement a different Concat processor for standard. Concat nodes always contain patterns (they can be regexp or literal, doesn't matter).

Currently, literal patterns are concatted with space. regexp patterns are concatted with .*. Now, with standard, it's possible to have literal and regexp patterns alternate in the input string for the first time, so the Concat behavior will be different (we don't want to always use space, but right now it does, and consequently, it just means that the regexp pattern is reduced to a literal string). Instead, the end state will work like this:

• Any sequence of regexp patterns like /foo/ /bar/ /baz/ will be AND-ed
• Alternation of regexp and literal patterns like /foo/ bar /baz/ will be ANDed
• Any sequence of literal patterns like foo bar baz will be concatenated with space (preserving literal search behavior as before).

Essentially, everything will be ANDed except for contiguous literal patterns, which will be space, as before. My intuition is that the AND meaning is more intuitive outside of the literal pattern behavior, because unlike literal patterns, regex patterns are explicitly delineated with /.../. For example, it would be a little silly to say /foo/ /bar/ if you prefer to concat those patterns--you would probably (should) prefer to just write /foo bar/.

Combining lucky search with other alternatives (and also the AND interpretation of literal patterns) will cover the entire spectrum of possibilities and hopefully crush ambiguity issues really well.

Does that explanation and plan jives with you?

[camdencheek]

Does that explanation and plan jives with you?

Yes, this sounds great. Thanks for explaining!