#3919: Or-patterns as GHC extension
---------------------------------+------------------------------------------
Reporter: BjornEdstrom | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version:
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonpj):
I think this would be a worthwhile thing to do. Or patterns are well
studied in the ML community -- many papers on pattern-match compilation
deal with them.
Whether we agreed to incorporate such a change into the HEAD of GHC would
depend on
* whether the implementation is modular (ie not complicating everything
else) and
* whether the syntax works smoothly with the rest of the language.
* whether a consensus emerged that the extra complexity cost was paid for
by the benefit.
I don't have time to say much more now, but here are some thoughts and
pointers
* Syntax is always surprisingly tricky, because Haskell's
syntactic space is very crowded. Remember, for example
that `(||)` is an existing operator symbol; are you going to steal it?
* Your example gives an 'or' between two whole equations. You might also
want to have an 'or' in a nested way, thus:
{{{
f [ (Left x, True) || (Right y, False) ] = ...
}}}
Here the or-pattern is embedded compositionaly inside a larger pattern.
* You need to check that the two disjuncts bind the same variables.
Places you'd need to change in the compiler
* Data type for patterns: `HsPat`
* Parser: `parser.y.pp`
* Renamer: `RnPat`
* Typecheck: `TcPat`
* Desugarer: `Match`
and probably some more besides.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3919#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
