RE: n + k patterns

2003-05-30 Thread Simon Peyton-Jones
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

2002-01-30 Thread Simon Peyton-Jones
| 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

2002-01-30 Thread Malcolm Wallace
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

2002-01-30 Thread Jon Fairbairn
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

2002-01-30 Thread John Launchbury
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

2002-01-30 Thread George Russell
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

2002-01-30 Thread Rijk J. C. van Haaften
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

2002-01-30 Thread Simon Peyton-Jones
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

2002-01-30 Thread Lennart Augustsson
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

2002-01-30 Thread carlos . scheidegger
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

2002-01-29 Thread Ross Paterson
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

2002-01-29 Thread Olaf Chitil
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

2002-01-29 Thread Simon Peyton-Jones
| 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

2002-01-29 Thread Mark P Jones
| 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

2002-01-29 Thread Simon Peyton-Jones
| 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

2002-01-29 Thread Lennart Augustsson
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

2002-01-29 Thread Lennart Augustsson
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.

1993-06-01 Thread hudak-paul
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.

1993-05-20 Thread Simon L Peyton Jones
|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

1993-05-19 Thread marc
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.

1993-05-19 Thread Kent Karlsson
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

1993-05-18 Thread kff
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

1993-05-18 Thread smk
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

1993-05-18 Thread wadler
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

1993-05-18 Thread Ken Sailor
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

1993-05-18 Thread wadler
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

1993-05-18 Thread Lennart Augustsson
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

1993-05-18 Thread Joe Fasel
|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

1993-05-18 Thread hudak-paul
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