December 2001 - Haskell

New extension in GHC: newtype deriving clause
by John Hughes 21 Dec '01

21 Dec '01

Simon PJ and I have come up with an extension to newtype deriving clauses which is intended to make it easier to make types abstract. Suppose you are about to write a type definition. You face a choice between defining it as a type synonym, and making it a new, potentially abstract type. Often a newtype may be the "right" choice, but that may require substantial extra work. Specifically, if the representation type already has a number of useful class instances, which you also want on the newtype, then a type synonym gives you them for free -- but a newtype definition forces you to write an instance declaration for each instance you want. These instance declarations are boring to write: they just strip off and put back the newtype constructor here and there, and call the representation instance. Especially galling is that in the implementation, the newtype constructor doesn't even appear -- so all your work is "for nothing", the dictionary for the representation type would actually work perfectly well for the new type also. The work of defining these instances may be enough to put you off making the new type abstract. The new extension allows you to derive these instances, just by adding the classes to the deriving clause of the newtype declaration. It's implemented in GHC already and will be part of the next release. I've appended the manual entry describing the extension to this message: that contains examples and a careful definition of when an instance can be derived. I'll just remark that you can also use this extension to emulate Hugs' restricted type synonyms. Suppose you want to implement an abstract type of sets as lists, and define the set operations without needing to constantly add and remove a newtype constructor. You can do so as follows: 1. Define a class containing the operations inside the abstraction barrier. This corresponds to giving the type signatures of these functions in the Hugs construct. class SetLike s where empty :: s a single :: a -> s a union :: s a -> s a -> s a member :: Eq a => a -> s a -> Bool (This isn't supposed to be a general Collection class: we're just defining the types of function on sets-as-lists), 2. Define an instance for the representation type. Of course, there's no need to mess with any newtype constructor here. instance SetLike [] where empty = [] single x = [x] union = (++) member = elem 3. Define a new Set type, and derive a class instance for it. newtype Set a = Set [a] deriving SetLike That's it. Of course, the Set operations are now overloaded, which has its own penalties, but nevertheless we managed to define operations on an abstract type without explicitly worrying about the constructor. Here's the manual entry: Extended deriving clause for newtype ==================================== When you define an abstract type using newtype, you may want the new type to inherit some instances from its representation. In Haskell 98, you can inherit instances of Eq, Ord, Enum and Bounded by deriving them, but for any other classes you have to write an explicit instance declaration. For example, if you define newtype Dollars = Dollars Int and you want to use arithmetic on Dollars, you have to explicitly define an instance of Num: instance Num Dollars where Dollars a + Dollars b = Dollars (a+b) ... All the instance does is apply and remove the newtype constructor. It is particularly galling that, since the constructor doesn't appear at run-time, this instance declaration defines a dictionary which is wholly equivalent to the Int dictionary, only slower! GHC permits such instances to be derived instead, so one can write newtype Dollars = Dollars Int deriving (Eq,Show,Num) and the implementation uses the same Num dictionary for Dollars as for Int. Notionally, the compiler derives an instance declaration of the form instance Num Int => Num Dollars which just adds or removes the newtype constructor according to the type. We can also derive instances of constructor classes in a similar way. For example, suppose we have implemented state and failure monad transformers, such that instance Monad m => Monad (State s m) instance Monad m => Monad (Failure m) In Haskell 98, we can define a parsing monad by type Parser tok m a = State [tok] (Failure m) a which is automatically a monad thanks to the instance declarations above. With the extension, we can make the parser type abstract, without needing to write an instance of class Monad, via newtype Parser tok m a = Parser (State [tok] (Failure m) a) deriving Monad In this case the derived instance declaration is of the form instance Monad (State [tok] (Failure m)) => Monad (Parser tok m) Notice that, since Monad is a constructor class, the instance is a partial application of the new type, not the entire left hand side. We can imagine that the type declaration is ``eta-converted'' to generate the context of the instance declaration. We can even derive instances of multi-parameter classes, provided the newtype is the last class parameter. In this case, a ``partial application'' of the class appears in the deriving clause. For example, given the class class StateMonad s m | m -> s where ... instance Monad m => StateMonad s (State s m) where ... then we can derive an instance of StateMonad for Parsers by newtype Parser tok m a = Parser (State [tok] (Failure m) a) deriving (Monad, StateMonad [tok]) The derived instance is obtained by completing the application of the class to the new type: instance StateMonad [tok] (State [tok] (Failure m)) => StateMonad [tok] (Parser tok m) As a result of this extension, all derived instances in newtype declarations are treated uniformly (and implemented just by reusing the dictionary for the representation type), except Show and Read, which really behave differently for the newtype and its representation. Derived instance declarations are constructed as follows. Consider the declaration (after expansion of any type synonyms) newtype T v1...vn = T' (TC t1...tp vk+1...vn) deriving (c1...cm) where TC is a type constructor, t1...tp are types, vk+1...vn are type variables which do not occur in any of the ti, and the ci are partial applications of classes of the form C t1'...tj'. The derived instance declarations are, for each ci, instance ci (TC t1...tp vk+1...vl) => ci (T v1...vl) where l is chosen so that T v1...vl is of the right kind for the last parameter of class Ci. As an example which does not work, consider newtype NonMonad m s = NonMonad (State s m s) deriving Monad Here we cannot derive the instance instance Monad (State s m) => Monad (NonMonad m) because the type variable s occurs in State s m, and so cannot be ``eta-converted'' away. It is a good thing that this deriving clause is rejected, because NonMonad m is not, in fact, a monad --- for the same reason. Try defining >>= with the correct type: you won't be able to. Notice also that the order of class parameters becomes important, since we can only derive instances for the last one. If the StateMonad class above were instead defined as class StateMonad m s | m -> s where ... then we would not have been able to derive an instance for the Parser type above. We hypothesise that multi-parameter classes usually have one ``main'' parameter for which deriving new instances is most interesting.

2 1

RE: New extension in GHC: newtype deriving clause
by Simon Peyton-Jones 21 Dec '01

21 Dec '01

| Simon PJ and I have come up with an extension to newtype | deriving clauses which is intended to make it easier to make | types abstract. This newtype-deriving stuff that John describes is fully implemented in the GHC in the repository (for those of you who are keen) and will be in the release of GHC 5.03 we are planning for early new year. Simon

1 0

RE: ICFP (Functional Programming) 2002: Call for Papers
by Simon Peyton-Jones 21 Dec '01

21 Dec '01

It's definitely 4-6 Oct. I'm sorry about the confusion. Simon | -----Original Message----- | From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk] | Sent: 21 December 2001 13:23 | To: haskell(a)haskell.org | Subject: Re: ICFP (Functional Programming) 2002: Call for Papers | | | > ICFP 2002: International Conference on Functional Programming | > Pittsburgh, 3--5 October 2002 | | The email announcement says 3-5 Oct, the webpage says 4-6 | Oct. Which are the true dates for ICFP? | | Regards, | Malcolm

1 0

ICFP (Functional Programming) 2002: Call for Papers
by Shriram Krishnamurthi 21 Dec '01

21 Dec '01

--------------------------------------------- * Calling all functional programmers! * * ICFP'02 needs you! * --------------------------------------------- ICFP 2002: International Conference on Functional Programming Pittsburgh, 3--5 October 2002 CALL FOR PAPERS http://icfp2002.cs.brown.edu/ Paper submission deadline: 21 March 2002 General Chair: Mitchell Wand, Northeastern University Program Chair: Simon Peyton Jones, Microsoft Research ICFP 2002 seeks original papers on the full spectrum of the art, science, and practice of functional programming. The conference invites submissions on all topics ranging from principles to practice, from foundations to features, and from abstraction to application. The scope covers all languages that encourage programming with functions, including both purely applicative and imperative languages, as well as languages that support objects and concurrency. You can find the full call for papers at http://icfp2002.cs.brown.edu/ Program Committee Matthias Blume (Lucent) Margaret Burnett (Oregon State University) Manuel Chakravarty (University of New South Wales) Matthew Flatt (University of Utah) Haruo Hosoya (Kyoto University) Uwe Nestmann (EPFL, Lausanne) Chris Okasaki (United States Military Academy) Norman Ramsey (Harvard University) David Sands (Chalmers University) Olin Shivers (Georgia Tech) Stephanie Weirich (Cornell) Joe Wells (Heriot Watt University)

2 1

RE: unsafePerformIO to give warnings
by Simon Marlow 21 Dec '01

21 Dec '01

Ian Lynagh writes: > Sorry, I meant "hugs and ghci only seem to print the warning the first > time I run the program", e.g. with > > module Main where > > import IOExts > > main :: IO() > main = trace "foo" (putStrLn "bar") > > in hugs: > > [...] > Type :? for help > Main> main > foobar > > Main> main > bar [snip] > and in ghci: > > Skipping Main ( q.lhs, ./q.o ) > Main> main > foo > bar > Main> main > bar [snip] This is because 'main' is a CAF: the act of reducing it to normal form the first time forces the warning to be printed, but thereafter the evaluated version is returned immediately. To subvert this behaviour, in GHCi you can say ':set +r' which causes all CAFs to be reverted between evaluations. Cheers, Simon

1 0

RE: unsafePerformIO to give warnings
by Simon Marlow 21 Dec '01

21 Dec '01

> If I want to give warnings when doing something and I don't care too > much about the order they appear in, can I use this? > > foo x = if success x then Just x > else warn "Working out x went wrong" Nothing > > warn :: String -> a -> a > warn s x = unsafePerformIO (hPutStrLn stderr s) `seq` x This is what IOExts.trace is for, BTW. > The hslibs docs say > > If the I/O computation wrapped in unsafePerformIO performs side > effects, then the relative order in which those side effects take > place (relative to the main I/O trunk, or other calls to > unsafePerformIO) is indeterminate. > > but it's not entirely clear on whether or not I could end up with 2 > warnings interspersed? It is possible to get warnings interspersed if you write something like warn ("abc" ++ warn "foo" "def") > And is it guaranteed that the warnings will be printed at some point? All that is guaranteed is that if an expression 'warn a b' is evaluated then 'a' will be evaluated to a String and then printed. > hugs and ghci only seem to print the first warning, but ISTR similar > problems happen with threads and got the impression that they were in > the wrong. Are you sure that laziness and/or optimisation aren't to blame for only getting a single warning? Given that you say Hugs also produces the same result, it sounds like a laziness issue. Cheers, Simon

2 1

RE: "The signature contexts in a mutually recursive group should all be identical"; why?
by Simon Peyton-Jones 21 Dec '01

21 Dec '01

[Note to the Haskell list. The question this thread is discussing is whether the H98 rule that all the functions in a mutually recursive group must have the same context, is a show stopper.] | Oeer. Come to think of it, if f is getting the dictionary | (in the real world | example) from the context, rather than from the existential | type, I fear it may be getting the wrong dictionary, and will | crash badly when I try to run the code. No I don't think that can happen. But I have thought of a test case data T = forall a. Eq a => MkT a a T | Nil f :: T -> Bool f Nil = True f (MkT x y t) = g x y t g :: Eq b => b -> b -> T -> Bool g x y t = (x==y) && f t Notice that (a) f and g are mutually recursive (b) They have different contexts in their type sig (c) If they were made the same, f would get an ambiguous type f :: Eq a => T -> Bool (d) Haskell's polymorphic recursion is essential here; each call to g may be at a different type So it looks to me that, in the presence of existentials, the H98 rule goes from being moot to being throughly awkward. Mark's THIH paper shows that there's no real need for the rule, because one can type-check the bindings without type sigs as a group, and then the ones with type sigs one by one. But what happens for pattern-bindings that bind more than one variable. Must all those variables have the same context? (I hope so.) Needless to say, I'm not proposing any changes in H98! But I thought the example would be of interest. Maybe it's well known, but it wasn't to me. Simon

2 1

Haskell 98 Christmas release
by Simon Peyton-Jones 21 Dec '01

21 Dec '01

In my Sisyphian task of finishing the Haskell 98 Report, I thought I would put out the current version before Xmas. http://research.microsoft.com/~simonpj/haskell98-revised It's substantially the same as the one I put out at the start of December, with three exceptions 1. The layout algorithm has changed (again). Simon M, Ian L and I are now all fairly confident that it is right, but we have been proved wrong before. 2. The "instance declaration wart" turned out to be closely connnected to some (unspecified) scoping issues in export lists. So I have nailed all that down. GHC and Hugs both now implement the new rules. 3. The avalance of email about the True Meaning of gcd 0 0 cannot have escaped your notice. I am too stupid to understand most of it, but my ill-informed conclusion is: a) there is a lot of support for gcd 0 0 = 0 b) but it is not universal support The strong default for H98 is "no change", so I've left gcd 0 0 as an error. However I have added some examples. Changes since the early-dec release are marked [Late Dec 2001] in the Bugs List, so you can find them easily. I don't think I know of any other loose ends. Happy reading. Simon

1 0

2002 Haskell Workshop
by Manuel M. T. Chakravarty 21 Dec '01

21 Dec '01

[My apologies if you receive multiple copies of this message] ------------------------------ PROVISIONAL CALL FOR PAPERS (Approval for PLI'02 pending) ------------------------------ 2002 Haskell Workshop Pittsburgh, PA, USA (3rd, 7th, or 8th October 2002; exact date to be announced) ================================== The purpose of the Haskell Workshop is to discuss experience with Haskell, and possible future developments for the language. The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), Montreal (2000), and Firenze (2001). For detailed information and key dates please consult http://www.cse.unsw.edu.au/~chak/hw2002/

1 0

unsafePerformIO to give warnings
by Ian Lynagh 20 Dec '01

20 Dec '01

Hi all If I want to give warnings when doing something and I don't care too much about the order they appear in, can I use this? foo x = if success x then Just x else warn "Working out x went wrong" Nothing warn :: String -> a -> a warn s x = unsafePerformIO (hPutStrLn stderr s) `seq` x The hslibs docs say If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. but it's not entirely clear on whether or not I could end up with 2 warnings interspersed? And is it guaranteed that the warnings will be printed at some point? hugs and ghci only seem to print the first warning, but ISTR similar problems happen with threads and got the impression that they were in the wrong. Thanks Ian

1 0