- Haskell - Haskell.org

Can a class define a default superclass function?
by Graham Klyne 06 May '03

06 May '03

It appears that it is not possible for a subclass to define a default for one of its superclass functions. In the example below, simply trying to declare the default method for (==) results in the error 'No member "==" in class "Pair"', which I think is consistent with [1]. But trying to include a signature for (==) in the specification of Pair results in a type error: Inferred type is not general enough *** Expression : eqPair *** Expected type : Pair a b c => a b c -> a b c -> Bool *** Inferred type : Pair a (b c d) (e f g) => a (b c d) (e f g) -> a (b c d) (e f g) -> Bool which also makes sense as (I assume) the new type signature for (==) is being picked up when using (==) to compare the component values. The closest I can see is to declare (say) eqPair as below, then define (==) = eqPair for each instance (as below). Is this a genuine restriction, or is there some way to avoid this? #g -- [1] http://haskell.org/onlinereport/decls.html#sect4.3.1 Example code: [[ -- Can a class define a default superclass method? class (Eq (a k v), Eq k, Eq v) => Pair a k v where newPair :: (k,v) -> a k v getPair :: a k v -> (k,v) eqPair :: a k v -> a k v -> Bool eqPair p1 p2 = (k1==k2) && (v1==v2) where (k1,v1) = (getPair p1) (k2,v2) = (getPair p2) -- or just: -- eqPair p1 p2 = (getPair p1) == (getPair p2) -- But can't say this: -- (==) :: a k v -> a k v -> Bool -- (==) = eqPair -- The simplest way I can see to define this is to define -- (==) per-instance using the default eqPair method of -- the Pair class, thus: newtype MyPair k v = P1 (k,v) instance (Eq k, Eq v) => Pair MyPair k v where newPair (x,y) = P1 (x,y) getPair (P1 (x,y)) = (x,y) instance (Eq k, Eq v) => Eq (MyPair k v) where (==) = eqPair ]] ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

3 2

How to construct large and fast Haskell programs ?
by Magnus Lindberg 06 May '03

06 May '03

Hi, I have some Haskell questions ! First, thank you Derek Elkins for your help regarding monadic transformers and functinal dependencies. Now, a(nother) question. When I create large programs in Haskell I tend to end up with a lot of variables which I pass around in monads. I use different kinds of (state) monads with different sets of variables for different tasks in the program. I wonder if it is it good to use many different monades? E.g. one monad for each big task in the program. All my monads have a function `randf' which operates on a StdGen (the StdGen is part of the monad state). I have rewritten the `randf' function for each monad. I also pass the StdGen explicitely between the different monads. I don't want to rewrite `randf' and pass around the StdGen. Is there any solution for this problem? Perhaps monad transformers could be to some help here. Perhaps one could create a state monad with a StdGen as state and also a `randf' function. Then the other monads could be buildt upon this state monad. Would this be a solution? However, if it would be a solution I wouldn't use it because I want my program to be fast (it should do "heavy" computations). If I use monad transformers I imagine that each "monadic instruction" will take longer time since both the StdGen monad and the monad built on the StdGen monad will be involved in the "monadic instruction". Every row in my program would then become a bit slower which I don't like - especially not since inner loops are written in the monad built on the StdGen monad. Am I right - will my code be much slower if I use monad transformers? Would you recommend writing functions one wants to be fast with as few monads as possible, e.g. only using the IO monad or no monad at all? One could then pass around parameters (which could have been part of a state) as arguments between different functions. This would eliminate the (CPU consuming?) implicit passing of a state between all "monadic instructions". Keen regards, Magnus Lindberg

1 0

LAST CHANCE - Contributions to HC&A Report (May 2003 edition)
by C.Reinke 06 May '03

06 May '03

The majority of promised contributions have already reached me, so after editing and a final check with the contributors I currently expect this edition to get out to you by the end of this week. However, due to various, miscellaneous, general, and even other circumstances, some contributions have been delayed and will only come in today or tomorrow. So, if you have any brief last minute contributions about your own Haskell work, and you can get them into my inbox by early Wednesday, they might still have a chance to get into this edition. Cheers, Claus PS. Little more than 2 weeks left until the Haskell Workshop submission deadline!-) -- Haskell Communities and Activities Reports http://www.haskell.org/communities/

1 0

help with GMap, dispatch, etc...
by Hal Daume III 06 May '03

06 May '03

I'm in the middle of writing a program for transforming haskell modules, a large amount of which is essentially renaming the HsNames inside. It is *almost* sufficient for me to simply write a function: transformName :: HsName -> QM HsName (QM is the monad I'm living in at the moment) and then simply apply a gmapM to the HsModule. The problem is that "almost" referenced above. Specifically, I need to do something special when I reach an HsFunBind in the source (basically, just push the local definitions into an environment held in the QM monad and then pop them back out when we leave). I have a feeling such a thing should be possible, but I haven't yet figured out how. My first attempt was essentially to try to do some sort of dispatch function using the gmap library. To simplify, consider: newtype Name = Name String deriving (Eq, Ord, Show) data Foo = Foo Name [Foo] | Bar Name deriving (Eq, Ord, Show) testFoo = Foo (Name "a") [Foo (Name "b") [Bar (Name "c"), Bar (Name "d"), Foo (Name "e") [Bar (Name "f")], Bar (Name "g")], Bar (Name "h")] with the obvious instance declarations of Term and Typeable. Now, we want a function which will replace every 'Name s' with 'Name (s++s)' and, when we reach a 'Foo s', we want to print ">s" onenter and "<s" on exit. we can do the first one with: doubleName :: Name -> IO Name doubleName (Name s) = return (Name (s++s)) everywhereM (mkM doubleName) testFoo which runs fine and produces the correct results. As for the printing, I want something like: flagFoo x | x "is a Name" = doubleName x | x "is a Foo s l" = do putStrLn ('>':s) recurse on s and l putStrLn ('<':s) | otherwier = gmapM flagFoo x or something like that. obviously I could do this by writing the recursion myself, but i'm trying to get around that. even if i could write something like: doName = doubleName doFoo x@(Foo s l) = do putStrLn ...; something x; putStrLn ... doFoo x = something x and then domsehting like: everywhereM (doName .|. doFoo) testFoo then that woudl be fine. I just don't want to have to write out all the other cases for doFoo that I don't care about, because for the real HsDecl, this is a *lot* of junk. Anyone know how to solve this problem? -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

2 1

String -> IO Handle -- generalized input
by Galen Menzel 05 May '03

05 May '03

Hello. I'm writing a little string-parsing function and I'd like it to be able to get character-at-a-time input from a file or a string. Is there a function that takes a String and returns an IO Handle that contains the contents of the String? Something like C++'s stringstream constructor? Or is there a better way to do this? Thanks very much. galen

1 0

fun deps and constraints in data decls
by Iavor Diatchki 05 May '03

05 May '03

> module Test where Hello, Both GHC and Hugs report an error on the example bellow, which to me seems wrong. Is this a bug, or am I missing something? > class C a b | a -> b > newtype C a b => T a = T a > t :: C a b => a -> T a > t = T The error reported is that "b" is an undefined type variable. Since "a" determines "b" using the functional dependency, I was expecting the example to work. I expected the type of the data constructor "T" to be as the one given in the type signature for "t", as I though that constraints on data/newtype declarations simply were added to the constructors. Both of the implementations are happy if I simply comment out the constraint, so they do not consider the type signature for "t" to be malformed in any way. bye iavor

1 0

LOPSTR 2003 (CFP)
by Wim Vanhoof 05 May '03

05 May '03

With apology for multiples copies. Deadline in 3 weeks ---------------------------------------------------------------------- International Symposium on Logic-based Program Synthesis and Transformation, LOPSTR'03 August 25 - 27, 2003 Uppsala, Sweden ---------------------------------------------------------- CALL FOR PAPERS ----------------------------------------------------------- http://www.cs.kuleuven.ac.be/~dtai/lopstr03/ ----------------------------------------------------------- The aim of the LOPSTR series is to stimulate and promote international research and collaboration on logic-based program development, and the symposium is open to contributions in logic-based program development in any language paradigm. LOPSTR 2003 will be held at the University of Uppsala, as part of PLI 2003 (Principles, Logics, and Implementation of High-Level Programming Languages), a confederation of conferences and workshops including ICFP 2003 (ACM-SIGPLAN International Conference on Functional Programming) and PPDP 2003 (ACM-SIGPLAN International Conference on Principles and Practice of Declarative Programming). Past events were held in Manchester, UK (1991, 1992, 1998), Louvain-la-Neuve, Belgium (1993), Pisa, Italy (1994), Arnhem, the Netherlands (1995), Stockholm, Sweden (1996), Leuven, Belgium (1997), Venice, Italy (1999), London, UK (2000), Paphos, Cyprus (2001), Madrid, Spain (2002). Since 1994 the proceedings have been published in the LNCS series of Springer-Verlag. LOPSTR also aims to be a lively, friendly forum for presenting and discussing work in progress, so it has a strong workshop character, in the sense that it is also intended to provide useful feedback to authors on their preliminary research. Formal proceedings of the symposium are produced only after the symposium, so that authors can incorporate this feedback in the published papers. Scope of the Workshop We solicit full papers as well as extended abstracts describing work in progress. Topics of interest cover all aspects of logic-based program development, all stages of the software life cycle, and issues of both programming-in-the-small and programming-in-the-large. The following is a non-exhaustive list of topics: * specification * synthesis * verification * transformation * specialisation * analysis * composition * reuse * optimisation * applications and tools * component-based software development * agent-based software development * software architectures * design patterns and frameworks * program refinement and logics for refinement * proofs as programs Submission Guidelines Authors can either submit extended abstracts (up to 6 pages) describing work in progress or they can choose to submit full papers (up to 16 pages in llncs format). Contributions should be written in English and should be submitted electronically in Postscript or PDF format to the program chairman at the following email address: Maurice.Bruynooghe(a)cs.kuleuven.ac.be. Prospective authors who have difficulties for the electronic submission may contact the chairman. Accepted papers have to be presented at the Symposium by one of the authors and will appear in the informal pre-proceedings distributed at the Symposium. Formal Proceedings After the workshop, authors of work that is judged mature for publication will be invited to submit a full paper. These will be reviewed according to the usual refereeing procedures, and accepted papers will be published in a final collection of papers which are expected to be published in the Lecture Notes in Computer Science series by Springer-Verlag. Accepted full papers that the PC considers of sufficient quality will be exempted from a second reviewing round. Important Dates May 25, 2003: submission deadline for full papers June 8, 2003: submission deadline for extended abstracts June 22, 2003: notification of authors August 1, 2003: deadline for informal pre-proceedings December 1, 2003: submission deadline for revised papers February 1, 2004: notification of authors Program Committee Elvira Albert (Spain) Roland Bol (Sweden) LOCAL ORGANISOR Maurice Bruynooghe (Belgium) PROGRAMME CHAIR Michael Butler (UK) Jim Caldwell (USA) Wlodek Drabent (Poland) Tom Ellman (USA) Norbert E. Fuchs (Switzerland) Robert Glück (Japan) Gopal Gupta (USA) Ian Hayes (Australia) Catholijn Jonker (the Netherlands) Andy King (UK) Mario Ornaghi (Italy) Maurizio Proietti (Italy) German Puebla (Spain) Julian Richardson (USA) Olivier Ridoux (France) Sabina Rossi (Italy) Wim Vanhoof (Belgium)

1 0

Point-Free Style : Haskell doesn't like it ?
by Ahn Ki-yung 05 May '03

05 May '03

I wan't to know why Haskell doesn't like pooint-free style. For example, 0) and 1) are Unresolved top-level overloading, but 2) is accepted by the type system. 0) show' = show 1) show' = (\x->show x) 2) show x = show x What are the differences between 0), 1) and 2) ? They must have the same type. Point-free style is consice and more functional, so I like it. I think quite many of functional programmers would prefer. It is especially annoying when using compoisitoins to define new function. I should write like this in order to pass the type system f x y = (g . h . k) x y instead of writing just compositions like below. f = g . h . k

4 3

Re: unsafe parsing
by oleg＠pobox.com 05 May '03

05 May '03

The following code works. I must admit though that I don't understand the problem. What is the expected result? Note that bmap is actually a type transformer, and 'funny' introduces a constraint via a run-time witness. data A = A deriving Show data B = B deriving Show data Cons x xs = Cons x xs deriving Show data Nil = Nil deriving Show class XTERM u where xtval:: u -> Char instance XTERM A where xtval _ = 'A' instance XTERM B where xtval _ = 'B' data BTERM = forall u. (XTERM u) => BTERM u xtmake 'A' = BTERM A xtmake 'B' = BTERM B instance Show BTERM where show (BTERM u) = show $ xtval u class XSEQ u where xsval:: u -> String isnil:: u -> Bool car:: u -> BTERM cdr:: u -> BSEQ instance XSEQ Nil where xsval _ = [] isnil = const True car = undefined cdr = undefined instance (XTERM v, XSEQ w) => XSEQ (Cons v w) where xsval _ = (xtval (undefined::v)):(xsval (undefined::w)) isnil = const False car _ = BTERM (undefined::v) cdr _ = BSEQ (undefined::w) data BSEQ = forall u. (XSEQ u) => BSEQ u instance Show BSEQ where show (BSEQ u) = show $ xsval u bcons (BTERM u) (BSEQ t) = BSEQ $ Cons u t xsmake [] = BSEQ Nil xsmake (x:xs) = bcons (xtmake x) $ xsmake xs bcar (BSEQ u) = car u bcdr (BSEQ u) = cdr u bmap f (BSEQ u) | isnil u = BSEQ Nil bmap f seq = bcons (f $ bcar seq) $ bmap f (bcdr seq) class FunnyMap u v | u -> v where funnymap:: u -> v instance FunnyMap A B where funnymap _ = (undefined::B) funny (BTERM u) = case xtval u of 'A' -> BTERM $ funnymap (undefined::A) -- 'B' -> BTERM $ funnymap (undefined::B) *Main> bmap funny $ xsmake "AAA" "BBB"

1 0

Monad transformers question
by Magnus Lindberg 04 May '03

04 May '03

{- Hi ! I have tried to write an "EnvState" monad transformer, but it is quite useless because when a function peeks at the state but ignores the environment (or vice versa) the code won't compile. GHC tells that the monad I use is no instance of the MonadEnvState, but I really think it is! An example: ( I attach the monad transformer file, MonadTrans2.hs, if someone wonders how EnvStateT looks (I have only written EnvStateT myself, my teacher has written the others some time ago (I think)) ) -} import MonadTrans2 data Env = Env Int data State = State Int type M = EnvStateT Env State IO f, g, h :: M () f = do (Env e, State s) <- getES -- This works since I show GHC return () -- exactly what Env and State I use ? g = do State s <- getS -- compile time error! return () h = do Env e <- getE -- compile time error! return () {- I have already told Haskell that the monad M uses an `Env' and a `State' (the `type M = ...') so why does GHC complain? The function `g' gives: No instance for (MonadEnvState (EnvStateT Env State IO) e State) arising from use of `getS' at envstate.hs:33 In a 'do' expression pattern binding: State x <- getS In the definition of `g': do State x <- getS return () This means that my environment-state monad is nearly useless, since all functions have to use both the state and the environment in order to compile. I thought the following could solve the problem: instance MonadEnvState M Env State since I then tell Haskell that M is an instance of MonadEnvState, but then the code won't compile: Illegal instance declaration for `MonadEnvState M Env State' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `MonadEnvState M Env State' Does anyone know what to do? Is this a problem with Haskell without any solution? Must one perhaps first make a state monad and then transform the state monad into an environment monad? Can't one have both a state and an environment in one single monad at the same time without these compiler errors? Thanks for any help ! Best regards, Magnus Lindberg -}

2 1