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 | fac (n + 1) = (n + 1) * fac n | | the following type | | / _ \ /\ /\/ __(_) | / /_\// /_/ / / | | GHC Interactive, version 5.04.2, for Haskell 98. | / /_\\/ __ / /___| | http://www.haskell.org/ghc/ | \/\/ /_/\/|_| Type :? for help. | | Loading package base ... linking ... done. | Loading package haskell98 ... linking ... done. | Compiling Main ( Fac.lhs, interpreted ) | Ok, modules loaded: Main. | *Main :t fac | forall a. (Num a, Ord a) = a - a | | The Report, however, states that | | 3.17.2 Informal Semantics of Pattern Matching | ... | An n+k pattern can only be matched against a value in the class Integral. | | Cheers, Ralf | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 report * So we should think what the best answer is 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. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 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 and Double? I'm not convinced that would be useful. f :: Double - Double f (n+1) = n Main print (f 3.0) 2.0 Main print (f 2.0001) 1.00010002 Main print (f 1.01) 1.00082740371e-10 Regards, Malcolm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 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 and Double? I dimly remember that the justification for having n+k was to allow inductive definitions, which only applies to Integral. I'd vote for keeping it as it is, too. Jón ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 a chicken. If anything, we should have restricted them to the very simplest case covered in the early textbooks, i.e. just Int. John | 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 report * So we should think what the best answer is 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. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 that (x+1)=y. 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). ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 change is non-de-stabilising on the rest of the report * So we should think what the best answer is 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. Personally I vote for keeping Integral. The strongest reason for my choice is that if we want to be sure the pattern is really correct, we need a bijection. For Integral, we have + and - to form one, but we can't construct one for Float and Double, though by this change they would be allowed in the pattern. Rijk-Jan van Haaften ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 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 change is non-de-stabilising on the rest of the report | * So we should think what the best answer is | | 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. | | Personally I vote for keeping Integral. The strongest reason | for my choice is that if we want to be sure the pattern is | really correct, we need a bijection. For Integral, we have + | and - to form one, but we can't construct one for Float and | Double, though by this change they would be allowed in the pattern. | | Rijk-Jan van Haaften | | ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 implementation teams didn't read the report. :-) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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, 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 be advisable in the case that Rational numbers were implemented explicitly with numerators and denominators). Besides that, what about deprecating n+k patterns in future Haskell reports? :) just my $0.02, Carlos Eduardo Scheidegger ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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. Btw., in 3.17.2 Informal Semantics of Pattern Matching the end of the following sentence should be changed: Matching a non-_|_ value x against a pattern of the form n+k (where n is a variable and k is a positive integer literal) succeeds if x=k, resulting in the binding of n to x-k, and fails if xk. There is no guarantee that if x=k == False then x k == True. So the sentence should end ..., and fails otherwise. Olaf -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 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 | cannot be a rational ... But then n+k patterns are a wart anyway. Actually, you can only use integer 'k's. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/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 indeed that's what GHC requires. | Do Hugs or nhc actually require Integral? | | Hugs demands Integral and the assumption that only one class is involved | seems deeply entwined in the code. 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 I wouldn't have thought this was up for grabs. (I'm thinking, for example, of the unnecessary same context restriction on mutually recursive binding groups, which has more practical impact, is very clearly a bug, and has not (AFAIK) been fixed in Haskell 98. Then there's David Wakeling's generalized gap proposal, and ...) All the best, Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 I wouldn't have thought this was up for | grabs. (I'm thinking, for example, of the unnecessary same | context restriction on mutually recursive binding groups, | which has more practical impact, is very clearly a bug, and | has not (AFAIK) been fixed in Haskell 98. Then there's David | Wakeling's generalized gap proposal, and ...) That is a fair point, and is exactly the reason I bother the Haskell list with these proposals rather than simply executing them. This is an unforced change, as you point out, but in fact GHC and NHC currently do one thing, and Hugs does another (i.e. follows the spec!). So some of us have to change our implementations. It clearly isn't a big deal, because no one has ever reported this as a practical problem. Other things being equal, it would be better to make the spec make as much sense as possible; hence my proposal. But if it's really hard to change Hugs, maybe we should leave the spec and change GHC and nhc. But you say it would be easy. I agree it's a moot point. I lean towards making the change, but I'm willing to be persuaded. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 :). 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 strong. All that is needed are Ord (for the = and -) and Num (for fromInteger), and indeed that's what GHC requires. Do Hugs or nhc actually require Integral? In any case, I propose to change Integral to Ord and Num. Does anyone think this is the Wrong Thing? How this bug has lasted so long I don't know. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 change | for Haskell 98, then I wouldn't have thought this was up for | grabs. (I'm thinking, for example, of the unnecessary same | context restriction on mutually recursive binding groups, | which has more practical impact, is very clearly a bug, and | has not (AFAIK) been fixed in Haskell 98. Then there's David | Wakeling's generalized gap proposal, and ...) That is a fair point, and is exactly the reason I bother the Haskell list with these proposals rather than simply executing them. This is an unforced change, as you point out, but in fact GHC and NHC currently do one thing, and Hugs does another (i.e. follows the spec!). So some of us have to change our implementations. 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. :-) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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 the semantics of case expressions, are not macros. A simple replacement of the right-hand-side for the left-hand-side with substitution of parameters does not give the intended semantics. The reason for this is that the translations make use of certain names defined in the standard prelude (see section 5.4), and macro substitution could result in the capture of these names by locally defined entities, or the use of a name in a context in which it is not defined at all because the part of the prelude in which it is defined has not been imported. The general rule is: the use of a name defined in the standard prelude in a translation intended to show the semantics of a construct always implies the definition in the standard prelude. Then, people can locally rebind as much as they want, but the constructs defined by translation will be unaffected. This sounds reasonable to me. -Paul
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 comprehensions etc.? (Via some unseen and unhidable | intermediary module.) Or are constructs that use hidden parts of the | standard prelude (according to their translations given in the report) | not available? Yes. No. Respectively. The Report is obviously not clear enough on this point. The wording given for translations (eg list comprehensions) that "map" refers to the Prelude "map" is meant to indicate that it refers to the Prelude "map" whether or not the latter is explicitly in scope. That's the consistent story for all special syntax, to answer the latter part of your message. Simon
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 defined (or locally rebound) function. If we keep this in mind there shouldn't be any problem. (Tell me if I'm wrong.) Greetings, Marc Rehmsmeier.
Re: n+k patterns
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 - Begin Included Message - From [EMAIL PROTECTED] Tue May 18 14:56:37 1993 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 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 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 - End Included Message -
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 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, and a wish for more flexible
syntax not hampered by special cases.
Ken
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: 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 of { x+k - e; _ - e' }
translates to
if e0 = k then { let { x' = e0-k } in e[x'/x] else e'
Which = and - does this refer to?
What if they have been locally rebound? E.g.
let x - y = x ++ f y
where f 0 = []
f (n+1) = f n
in [] - 0
Does the translated - still refer to the method in PreludeCore or
to the - in scope?
-- Lennart
PS. I'd like to start the "Ban n+k patterns"-movement, any followers?
- End Included Message -
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 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
