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
| 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
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
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.
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
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
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
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
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
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,
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.
| 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
| 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
| 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
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
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
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
|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
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
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
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
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:
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
|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
24 matches
Mail list logo
