Some thoughts on Member Patterns as parser developer

[Brian Goetz]

On 4/29/2024 10:02 AM, Olexandr Rotan wrote:
> I think I did a really poor job expressing my thoughts in the first 
> message. I will try to be more clear now, along with some situations I 
> have encountered myself.
>
> Assume we have a stateless math expressions parser. For simplicity, 
> let's assume that we split expressions into several types: 
> "computation-heavy", "computation-lightweight", "erroneous" (permits 
> null as input) and "computation-remote" (delegate parsing to another 
> service via some communication protocol), and types can be assigned 
> heuristically (speculatively). For some tasks, we need to perform some 
> pre- and postprocessing around core parsing logic, like result 
> caching, wrapping parsing into virtual thread and registering it in 
> phaser etc., for others - log warning or error, or fail parsing with 
> exception.

If you are envisioning side-effects, then I think you are already 
abusing patterns.  Patterns either match, or they don't, and if they do, 
they may produce bindings to describe witnesses to the match. Exceptions 
are not available to you as a normal means of "something went wrong"; in 
writing patterns (you should think of throwing an exception from a 
pattern declaration as being only a few percent less drastic than 
calling System.exit()).

Patterns, as explained in the various writeups, are the dual 
(deconstruction) of certain methods (aggregations.)   I don't see the 
duality here.  (If I had to guess, you're trying to bootstrap your way 
to parser combinators with patterns, but that's a different feature.)  
So I'm still not sure that you're using patterns right, so I still want 
to focus on that before we start inventing new features.

Case patterns are a form of ad-hoc exhaustiveness, to be used only when 
other sources of exhaustiveness (e.g., enums, sealed types, ADTs) fail.  
It isn't clear to me yet that these other sources have failed.