Simplicity of pattern matching semantics, not of implementation (we all knew how to implement it). Miranda had non-linear patterns, but nobody really argued for them in Haskell. If Haskell had them, I'd not argue to have them removed, but nor will I argue to add them.
-- Lennart On Fri, May 15, 2009 at 1:19 PM, Conor McBride <co...@strictlypositive.org> wrote: > > On 15 May 2009, at 12:07, Lennart Augustsson wrote: > >> In the original language design the Haskell committee considered >> allowing multiple occurrences of the same variable in a pattern (with >> the suggested equality tests), but it was rejected in favour of >> simplicity. > > Simplicity for whom, is the question? My point is > only that there's no technical horror to the proposal. > It's just that, given guards, the benefit (in simplicity > of program comprehension) of nonlinear patterns over > explicit == is noticeable but hardly spectacular. > > Rumblings about funny termination behaviour, equality > for functions, and the complexity of unification (which > isn't the proposal anyway) are wide of the mark. This > is just an ordinary cost-versus-benefit issue. My guess > is that if this feature were already in, few would be > campaigning to remove it. (By all means step up and say > why!) As it's not in, it has to compete with other > priorities: I'm mildly positive about nonlinear > patterns, but there are more important concerns. > > Frankly, the worst consequence I've had from Haskell's > pattern linearity was just my father's derision. He > quite naturally complained that his programs had lost > some of their simplicity. > > All the best > > Conor > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe