January 2002 - Haskell

RE: Report Issues
by Simon Peyton-Jones 04 Jan '02

04 Jan '02

Yes, that's a good point. I think nub should be defined as nubBy (==), not as nubBy (not . (/=)). I'll make it consistently so. Simon | -----Original Message----- | From: Janis Voigtlaender [mailto:voigt@orchid.inf.tu-dresden.de] | Sent: 04 January 2002 11:07 | To: haskell(a)haskell.org | Subject: Report Issues | | | Simon Peyton-Jones wrote: | > | > Folks, | > | > You have all been eating too much Xmas pudding. Only one | > Haskell98 Report issue has arisen since my release of 21 Dec. | | OK, here comes a rather trivial issue regarding the libraries: | | Section 7.6 of the Library Report gives the following example | definition of nub: | | nub :: (Eq a) => [a] -> [a] | nub [] = [] | nub (x:xs) = x : nub (filter (\y -> x /= y) xs) | | But then, in Section 7.9, the following actual implementation | is given: | | nub :: Eq a => [a] -> [a] | nub = nubBy (==) | | nubBy :: (a -> a -> Bool) -> [a] -> [a] | nubBy eq [] = [] | nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not | (eq x y)) xs) | | The two definitions are only equivalent, if for all x and y | holds that | (x /= y) | and | (not (x == y)) | are equivalent. | While this is true for all basic types, and is also true for | user defined instances of Eq, if the programmer specifies | only one of the two functions (==) or (/=) and leaves the | other one at the default method, nobody can prevent me from | writing an instance declaration where I define (==) and (/=) | without adhering to the duality. This might be stupid to do, | but still it contradicts the report, right? | | Janis. | | | -- | Janis Voigtlaender | http://wwwtcs.inf.tu-dresden.de/~voigt/ | mailto:voigt@tcs.inf.tu-dresden.de | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

3 2

Storable Class
by Carolina Mattos Cavalcanti 04 Jan '02

04 Jan '02

Hi, I´m Carol, and I´m just need some help to find the predefined types from the storable class. I´ll be thankfull if you could answer.

3 3

Please add me to the Haskell mailing list.
by Andrew Hamilton 04 Jan '02

04 Jan '02

Thanks. Regards, Andrew Hamilton tel: +44 (0) 7956 396396 email: ah93(a)zepler.org.uk

1 0

Haskell 98 sections
by Simon Peyton-Jones 04 Jan '02

04 Jan '02

Folks, You have all been eating too much Xmas pudding. Only one Haskell98 Report issue has arisen since my release of 21 Dec. The issue is this: Section 3.5 says that (a + b +) is a valid operator section (meaning \x -> a + b + x) because (+) is right associative. But this is contradicted by the actual syntax, which only has the productions: aexp ::= '(' exp(i+1) qop(a,i) ')' | '(' qop(a,i) exp(i+1) ')' (Here 'a' ranges over the possible operator associativities of left, right, non-assoc, while i ranges over precendence levels.) This is clearly an inconsistency. I propose to fix the syntax in the way proposed by Simon and Ian (in a thread on GHC-bugs), by adding the following productions for aexp. '(' lexp(i) qop(l,i) ')' '(' qop(r,i) rexp(i) ')' This actually follows the way that qfunlhs is defined. There is no ambiguity, because an exp(i+1) is not an lexp(i). This should bring the formal syntax into line with the words in Section 3.5. Can anyone think of a reason why this won't work? Simon

2 1

>Our apologies for the delay. The new FREE download of DPA is ready now at:
by Create FREE Digital Web Books 04 Jan '02

04 Jan '02

1 0

RE: punning in GHC?
by Simon Peyton-Jones 02 Jan '02

02 Jan '02

Punning was removed from Haskell some while ago, I believe when Haskell 98 was fixed in Feb 1999. See the Preface section 0.4.1 Simon | -----Original Message----- | From: Iavor S. Diatchki [mailto:diatchki@cse.ogi.edu] | Sent: 26 December 2001 18:55 | To: haskell(a)haskell.org | Subject: punning in GHC? | | | hi there, | | i just discovered that GHC does not support punning with the | -fglasgow-exts | option. is there another flag to turn this on or has it been | completely | removed? if so could we have it back - i really like the feature (in | patterns anyways) and use it (hugs -98 supports it). i don't | particularly | care that it is not in haskell 98 as i rarely write haskell | 98 programs. | | by the way before posting this i did a search on "punning" | through the | mailing list archive to see if someone asked this already. i | couldnt find | anything but it seems that since 1997 there were 7 posts on | "punning" and | all of them seemed to agree that it was a useful feature, so | why was it | removed? | | bye | iavor | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

2 1

Re: instances and modules
by Feuer 01 Jan '02

01 Jan '02

> 2. A missing method definition is assumed to be bottom. > (I don't like this rule. Ghc with suitable options warns in such case. > This definitely sounds like a bad idea... seems to violate intuition about what an instance of a class is... if you can't define a method of the class, you probably don't belong in that class. >The first point is important. It's possible that an overloaded function >in the next version of a library is promoted to a method with a default >definition, and then existing code using that class doesn't break. Understood. Not sure what I think of it. Wouldn't it be better for the new library to include a new class deriving from the old? That would more clearly indicate the relationship... if the class itself changes, the instances should change too.

1 0

Re: instances and modules
by Marcin 'Qrczak' Kowalczyk 01 Jan '02

01 Jan '02

Mon, 31 Dec 2001 22:52:44 -0800, Feuer <feuer(a)his.com> pisze: > I don't understand how a type can be considered an instance of a > class if it doesn't provide all the methods of that class. 1. A method can have a default definition. 2. A missing method definition is assumed to be bottom. (I don't like this rule. Ghc with suitable options warns in such case.) The first point is important. It's possible that an overloaded function in the next version of a library is promoted to a method with a default definition, and then existing code using that class doesn't break. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

1 0

instances and modules
by Feuer 01 Jan '02

01 Jan '02

Some discussion has gone on recently regarding class methods that are and are not passed across module boundaries. One thing that struck me as rather odd was that some/many/all people thought it was reasonable to have module M (C(a)) where class C t where a::... b::... module N (.....) where import M instance C Int where a=..... I don't understand how a type can be considered an instance of a class if it doesn't provide all the methods of that class. Why not make all of these rules much simpler by requiring that a module N can contain an instance declaration for class M.C if, and only if, M exports M.C(..) and N imports M.C(..) (either qualified or unqualified)? I don't see why anyone would want to do something silly like import qualified M as P(a) import qualified M as Q(b) but even if this is useful, I don't think it should be enough to allow an instance declaration for C. The programmer should be required to explicitly say import qualified M as R(..) IMVHO, it should not even be legal to have an instance declaration that imports C(a,b), but that's just me. David Feuer

1 0