### Re: [GHC] #851: Incomplete-pattern checking for n+k patterns is not implemented

#851: Incomplete-pattern checking for n+k patterns is not implemented ---+ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low

### Re: [GHC] #3382: Panic in tidyNPat when using N+k patterns with overloaded strings

#3382: Panic in tidyNPat when using N+k patterns with overloaded strings -+-- Reporter: batterseapower|Owner: Type: bug | Status: closed

### [GHC] #3382: Panic in tidyNPat when using N+k patterns with overloaded strings

#3382: Panic in tidyNPat when using N+k patterns with overloaded strings -+-- Reporter: batterseapower| Owner: Type: bug | Status: new Priority: normal

### RE: [Haskell-cafe] (n+k) patterns

Richard O'Keefe wrote: The thing is that it really seems bizarre to see this one feature singled out for non-implementation. If I can do the equivalent of n+k patterns by programming in the *type system*, why *not* in a pattern? Do you mean by something like the following? data Z = Z

### Re: [GHC] #851: Incomplete-pattern checking for n+k patterns is not implemented

#851: Incomplete-pattern checking for n+k patterns is not implemented --+- Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone

### Re: [GHC] #851: Incomplete-pattern checking for n+k patterns is not implemented

#851: Incomplete-pattern checking for n+k patterns is not implemented ---+ Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone

### Erroneous warning with n+k patterns

Hi all, This function: g :: Int - Int g (x+1) = 1 g _ = 0 (erroneously) gives this warning: Warning: Pattern match(es) are overlapped In the definition of `g': g _ = ... I'm not sure if this is covered by the first item on

### Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

L.S., On Thu, 11 Dec 2003 06:23:51 -0800, Iavor S. Diatchki [EMAIL PROTECTED] wrote: : : Henk-Jan van Tuyl wrote: 1) It takes no effort, once you are use to it, to code without n+k patterns; this does not seem like a good argument. there are many other features like that in haskell

### bugs from n+k patterns (was: Re: Preventing/handling space leaks)

hi, first here is why i think n+k patterns are problematic; 1) they lead to some parsing awkwardness (e.g. when n+k pattern bindings are involved, but those don'treally make much sense anyways) 2) in haskell as it is, patterns are associated with algebraic datatypes, and n+k patterns may

### Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

On Thu, 11 Dec 2003 06:23:51 -0800 Iavor S. Diatchki [EMAIL PROTECTED] wrote: ... Henk-Jan van Tuyl wrote: ... 2) It is likely, that n+k patterns dissapear in the next Haskell standard. If you don't like to rewrite, test and debug all your software every few years, don't use any language

### Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

The n+k pattern issue inspired endless debates on the Haskell committee and this feature was considered for removal in nearly every iteration of the Haskell report. We all agreed that n+k is extremely ad-hoc but that certain programs can be expressed slightly more elegantly using them.

### RE: n + k patterns

Good point. Fixed in the head, but not in 6.0 Thanks Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Ralf Hinze | Sent: 28 May 2003 20:40 | To: GHC bugs | Subject: n + k patterns | | GHCi infers for | | fac 0 = 1

### n + k patterns

GHCi infers for fac 0 = 1 fac (n + 1) = (n + 1) * fac n the following type / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_|

### RE: n+k patterns

| hbc is on the Integral side, if that counts. :-) | Just because ghc doesn't follow the spec isn't a good reason | to change the spec. :-) I absolutely didn't say that! All I'm saying is * Two of the four impls have to change regardless * The change is non-de-stabilising on the rest of the

### RE: n+k patterns

view is that (n+k) patterns are evil, so it doesn't really matter what we decide. :-) No, seriously, I'm a little worried about widening the range of numeric types for which (n+k) patterns are supposed to work. I can (just about) imagine wanting to use Rationals in an (n+k) pattern, but Float

### Re: n+k patterns

. My view is that (n+k) patterns are evil, so it doesn't really matter what we decide. :-) No, seriously, I'm a little worried about widening the range of numeric types for which (n+k) patterns are supposed to work. I can (just about) imagine wanting to use Rationals in an (n+k) pattern

### Re: n+k patterns

I strongly disapprove of n+k patterns from a whole-language taste perspective, so I am most unkeen to broaden their scope. Because they are such a language kludge already it simply doesn't make sense to try to reason rationally about what the best answer for them is. It's like putting lipstick

### RE: n+k patterns

I too am against broadening the scope of n+k patterns, for reasons that others have already given. In particular, I am absolutely against allowing n+k patterns to be used for Float/Double. If n+k patterns are to be meaningful at all, you want matching y against x+1, you want a unique x

### RE: n+k patterns

At 03:27 30-01-02 -0800, Simon Peyton-Jones wrote: | hbc is on the Integral side, if that counts. :-) | Just because ghc doesn't follow the spec isn't a good reason | to change the spec. :-) I absolutely didn't say that! All I'm saying is * Two of the four impls have to change regardless * The

### RE: n+k patterns

OK, OK, I give in! Integral it remains. I repent. Simon | -Original Message- | From: Rijk J. C. van Haaften [mailto:[EMAIL PROTECTED]] | Sent: 30 January 2002 17:00 | To: Simon Peyton-Jones | Cc: [EMAIL PROTECTED] | Subject: RE: n+k patterns | | | At 03:27 30-01-02 -0800, Simon

### Re: n+k patterns

Simon Peyton-Jones wrote: | hbc is on the Integral side, if that counts. :-) | Just because ghc doesn't follow the spec isn't a good reason | to change the spec. :-) I absolutely didn't say that! All I'm saying is * Two of the four impls have to change regardless Only because two of the

### RE: n+k patterns

, but this reason, together with the fact that n+k patterns were designed to be used in inductive definitions do make me strongly favor the restriction of n+k patterns to the class Integral (Malcolm Wallace pointed out that there may be a use for Rational n+k patterns, but I think it would only

### Re: n+k patterns

In any case, I propose to change Integral to Ord and Num. I agree. And nhc98 seems to actually implement this. Nonetheless I find using n+k patterns for floating point numbers pretty horrible. And it raises the question why k cannot be a rational ... But then n+k patterns are a wart anyway

### RE: n+k patterns

at http://research.microsoft.com/~simonpj/tmp/exps.html The numbered items in the Informal Semantics of Pattern Matching are substantially changed and IHMO much clearer. | Nonetheless I find using n+k patterns for floating point | numbers pretty horrible. And it raises the question why k

### RE: n+k patterns

| On Tue, Jan 29, 2002 at 07:36:56AM -0800, Simon Peyton-Jones wrote: | The Haskell Report says of n+k patterns: | | A n+k pattern can only be matched against a value in | the class Integral. | | This seems far too strong. All that is needed are Ord (for the =) | and Num

### RE: n+k patterns

| Hugs demands Integral because that's what it was told to do | to follow the report. So in that sense, yes, the code | depends on having only one class. But it would be easy for | someone to change that. | | Then again, if we're following the rules of minimal change | for Haskell 98, then

### Re: n+k patterns

:). Since this is not a typo, I don't see why it should be changed unless there is some really good reason. -- Lennart Simon Peyton-Jones wrote: Folks The Haskell Report says of n+k patterns: A n+k pattern can only be matched against a value in the class Integral. This seems far too

### Re: n+k patterns

Simon Peyton-Jones wrote: | Hugs demands Integral because that's what it was told to do | to follow the report. So in that sense, yes, the code | depends on having only one class. But it would be easy for | someone to change that. | | Then again, if we're following the rules of minimal

### Haskell 1.3 (n+k patterns)

. I don't believe it. I teach an introductory FP course including induction. I introduce structural induction directly, and the students have no problem with it. When I have tried to talk to individuals about natural number induction using (n+k) patterns, then the problems start. Because they are so

### Re: Haskell 1.3 (n+k patterns)

jl writes: I feel the need to be inflamatory: I believe n+k should go. Again, I agree completely. Let's get rid of this horrible wart once and for all. It's a special case that makes the language more difficult to explain and implement. I've hardly seen any programs using it so I don't

### Re: n+k patterns, etc.

I think that we should try a different approach, forget about the importing mechanism, and make a single statement defining the intended semantics. Section 1.2 (The Haskell Kernel) is the place. I propose adding the following. The translations given, and the identities given for

### Re: n+k patterns, etc.

|What if (the appropriate parts of) the standard prelude is | explicitly *not* imported: | | import Prelude () | or | import Prelude hiding(map) | | (see section 5.4.3). | |Are then the hidden parts of the standard prelude still available via | n+k patterns, list

### Re: n+k patterns

From my point of view (n+k)-patterns have a very special meaning. This natural numbers should be considered as a type like this: data Nat = Zero | Succ Nat Therefore a (n+k)-pattern is an abbreviation for Succ(Succ(...Zero...)). It's obvious that "+" in "(n+k)" doesn't m

### Re: Successor patterns in bindings and n+k patterns

And now for a little quiz. What's the value of the following (legal) Haskell expression? (Don't try it with hbc, it fails.) let (+) + 1 + 1 = (+) in 1 + 1 Given infixl 6 + (since you can't change this without renaming!): (+) + 1 + 1 == lpat6 + pat7

### Re: Successor patterns in bindings and n+k patterns

And now for a little quiz. What's the value of the following (legal) Haskell expression? (Don't try it with hbc, it fails.) let (+) + 1 + 1 = (+) in 1 + 1 This is illegal syntax!! (+) and (the second) + are the same variable, thus violating the linearity constraint for

### Re: Successor patterns in bindings and n+k patterns

Another strange thing about n+k patterns. Its definition uses = , but = is not part of the class Num. Does that mean that n+k patterns have to be instances of class Real? One could leave it class Num, if the translation were expressed in terms of "signum" rather than "="

### Re: Successor patterns in bindings and n+k patterns

| Another strange thing about n+k patterns. | | Its definition uses = , but = is not part of the class Num. | Does that mean that n+k patterns have to be instances of class Real? Certainly. In fact, they're really meant to apply only to class Integral (and it would be natural numbers, if we

### Re: n+k patterns

Date: Tue, 18 May 93 15:55:42 +0200 From: Lennart Augustsson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: n+k patterns Both (=) and (-) belong to classes defined in PreludeCore, and hence cannot be rebound. This was a deliberate decision, made in order to turn your

### Re: n+k patterns

operators help, but what about nice multiple token symbols like { } ? So, minimally, I am in favor of the local redefinition of symbols like '+' and '=', and think it unfortunate that there is a clash between the redefinition and treatment of n+k patterns. This is a vote for dumping n+k patterns

### n+k patterns

Phil Wadler says: You are quite right. I'd forgotten about local rebinding, because I feel that all local rebinding should be disallowed. Anyone want to start a movement to eliminate local rebinding? (1/2 :-) Cheers, -- P And *I* think we should stop using names altogether and

### Re: n+k patterns

: Lennart Augustsson [EMAIL PROTECTED] Subject: n+k patterns Date: Mon, 17 May 93 22:25:03 +0200 To: [EMAIL PROTECTED] Could those in charge of the formal semantics of Haskell (yes, that's you folks in Glasgow!) tell me what the meaning of n+k patterns are? In the report it says that case e0

### Re: n+k patterns

the problem I state does occur. OK, I think that (=), (-), etc. should refer to those from PreludeCore, but it doesn't say anywhere. Another question along the same lines: What if (+) has been rebound? Are n+k patterns still allowed? -- Lennart

### Re: n+k patterns

|Another question along the same lines: What if (+) has been rebound? |Are n+k patterns still allowed? | |-- Lennart The answer should be that n+k patterns are still allowed, but (+), (-), and (=) from PreludeCore are used in the translation. --Joe