clunky env ((Find_in env) val1) ((Find_in env) val2) = val1 + val2
Find_in is a PatternSynonym – or to be more precise, (Find_in env) acts as the PatternSynonym; inside the parens is a use of the leftwards-bound env, not a fresh binding.
Of course I just plucked that double-parens syntax out of thin air. I’m thinking:
- That syntax is valid in an expression, and is merely equivalent to applying the constructor to two arguments – as we’d want in a build context.
- That syntax isn’t currently valid in a pattern match (you must put the constructor ‘flat’ with its arguments) – so it won’t upset existing code.
Or something like …
clunky env (Find_in env ? val1) (Find_in env ? val2) = val1 + val2
The ? can’t currently be part of a pattern, but I’m loath to co-opt another char with special meaning.
pattern (Find_in env) val <- lookup env -> Just val
Vars bound inside ( ... ) on LHS of pattern decl must appear on LHS of the view -> in the definition. But I want to root ViewPatterns out of the language entirely:
pattern (Find_in env) val <- _v | Just val <- lookup env _v
The implementation can under-the-covers revert to the ViewPattern mechanism if it must.
There’s independent reasons for wanting pattern decls to be smarter: too often you need to split what could be a implicitly bidirectional decl (single equation with =) into explicitly bidir (two equations, the top with <-) because there’s no smarter way to express what currently can only be a ViewPattern.)