### 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

### 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

I argued that (Num a, Ord a) makes most sense to me. You argued that (Integral a) was a conscious choice (something I don't remember but I'm sure you're right), and is the right one anyway. I'd be interested to know what others think. If there's any doubt, we'll stay with Integral. My

### Re: n+k patterns

I argued that (Num a, Ord a) makes most sense to me. You argued that (Integral a) was a conscious choice (something I don't remember but I'm sure you're right), and is the right one anyway. I'd be interested to know what others think. If there's any doubt, we'll stay with Integral.

### 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 on

### 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 such

### 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

On 30 Jan 2002, at 12:01, [EMAIL PROTECTED] wrote: Yet for floats there may not be such an x (y = positive zero), or there may be more than one (y=2^n with n chosen so that 2^n+1 is not exactly representable but 2^n-1 is, then x could be 2^n or 2^n-1). Well, I am just a newbie in Haskell,

### 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 (for - and fromInteger), and

### 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

| Btw., in 3.17.2 Informal Semantics of Pattern Matching | the end of the following sentence should be changed: Actually I've changed the entire wording of that section in consultation with Ross who has read it rather carefully. You can find the current draft of the expressions chapter at

### 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 (for - and

### 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

Well, it was a deliberate decision to limit the n+k pattern to class Integral because people at that time felt that n+k was something that should only be used with integers. So it's not a fluke, it was quite deliberate. I kind of like Integral for this (as much as I can like anything about n+k

### 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

### 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 mean a somewhere else

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

Some more questions concerning some constructs in Haskell: 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

### Re: n+k patterns

Lennart Augustsson [EMAIL PROTECTED] writes: PS. I'd like to start the "Ban n+k patterns"-movement, any followers? Count on me! I guess this makes it an organized movement ... two persons (movement) that know about each other (organized). Cheers, Karl-Filip

### Re: n+k patterns

Phil wrote: Both (=) and (-) belong to classes defined in PreludeCore, and hence cannot be rebound. This was a deliberate decision, made in order to turn your point into a non-problem. Long live (n+k)! -- P The Report tries to handle this by "always implicitly importing"

### 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

I like the capability to redefine syntax. For example, I would like to be able to define syntax that looks like EBNF when writing parsers. I would like to be able to write E = T {(`+`|`-`) T} rather than e = concat1 (t,zeroOrMore (concat2 (alternative (lit '+',lit '-'),t))) Of course infix

### 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 point into a non-problem. Long live (n+k)! -- P - Begin Included Message - From [EMAIL PROTECTED] Mon May 17 21:33:41 1993 From:

### 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 point into a non-problem. It's true that things from PreludeCore cannot be rebound on the top level, but they can be rebound locally. So the

### 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

### Re: n+k patterns

The Haskell Committee was well aware of the problem of name capture in syntactic expansions. We discussed various solutions and opted for the simplest (if not most formal): whenever a name freshly appears on the right side of a translation, add a comment that says where it came from. If you