- Haskell-Cafe - Haskell.org

Simulating OO programming with type classes; writing a factory fu nction
by Bayley, Alistair 01 Jun '05

01 Jun '05

I've been experimenting with simulating OO programming in Haskell (why, you might ask? Because I'm trying to port a non-trivial piece of software, and I want to respect the original design, at least to begin with). I've been trying the technique illustrated by Ralf Laemmel: http://homepages.cwi.nl/~ralf/OOHaskell/src/interpreter/extensible.hs There's a small problem: how to write a factory function that returns values of various subtypes. The makeSubType function below won't compile, obviously because the returns types are different (they're not the same 'm'). I realise that I'm looking for something that Haskell doesn't natively do, so my question is: is there some kind of workaround that'll give me the ability to write factory functions? (No doubt there's some obvious trick that I've missed :-) I'm aware of http://homepages.cwi.nl/~ralf/OOHaskell/ , which will be my technique of last resort. I was fond of Ralf's extensible interpreter example because it's quite lightweight, but if there's no way around the factory problem, so be it. Alistair. ------------------------------------------- -- Toy OO example with subtyping module Main where main = print "boo" -- class to represent OO base class class BaseClass c -- each subtype of BaseClass is a separate datatype data SubBase1 = SubBase1 Int data BaseClass c => SubBase2 c = SubBase2 c instance BaseClass SubBase1 instance BaseClass (SubBase2 c) -- methods of BaseClass defined with new class class BaseClass c => Method c where -- illegal: can't return values of type c; can only consume them method1 :: c -> Int -> c method2 :: c -> Int -- install each subtype (datatype) as instance of Method instance Method SubBase1 where method1 _ i = SubBase1 i method2 (SubBase1 i) = i instance Method c => Method (SubBase2 c) where -- This one fails, because must return polymorphic value, not concrete --method1 _ i = SubBase2 (SubBase1 5) method1 x i = x method2 x = 2 -- Also, cannot make factory function: --makeSubType :: (Method m) => String -> m makeSubType s = if s == "SubBase1" then SubBase1 3 else SubBase2 (SubBase1 4) ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 2

Unexported functions are evil
by Peter Simons 31 May '05

31 May '05

Please pardon the tendentious subject, but I felt like making a clear statement. ;-) I was wondering: Is there any reason why you would have a function in one of your modules and _not_ export it? I ask because I have _never_ had problems with a module exporting too much, but I have had problems with modules exporting too little quite frequently. The reason why I like purely functional languages like Haskell is that it is virtually impossible to write code that cannot be reused. So why would you exclude other modules from reusing you code? The only reason I could think of is that a function is considered to be "internal", meaning: You don't want users of the module to rely on the function still being there (or still working the same way) in any of the next revisions. On those occasions, however, why not put the function into a module, say "Foo.Bar.Private" and import it into "Foo.Bar" from there? Then those people who enjoy playing with fire _can_ use it, and everybody else will not. Is there something I missed? Peter

16 27

re: Python
by Stijn De Saeger 31 May '05

31 May '05

> On 27/05/05, John Goerzen <jgoerzen(a)complete.org> wrote: > > Yes, but actually much of that is slated for removal from the Python > > language in future versions. See > > > > http://www.python.org/peps/pep-3000.html > > I still can't believe that Guido will get away with this... Yes. Many people I know state the functional part as a big reason why they chose python. Basically, before Python 3000 a number of scenarios are thinkable : - The python community will just bite their lip and take it. - There'll be some skirmishes and the proposal will get shot down after a small revolution. (not likely) - python will get a second -- more functional -- branch coexisting with the standard. I personally can see this last scenario happen, for some reason. I know it's not even being developed yet, but does anyone know what date python 3000 is aiming at? s.

3 2

RE: [Haskell-cafe] Compiling GHC 6.2.2 without ghci
by Simon Marlow 31 May '05

31 May '05

On 25 May 2005 19:39, Jesper Louis Andersen wrote: > How do you compile GHC 6.2.2 without compiling the ghci (ghc > interactive)? I only need this as a stepping stone to GHC 6.4, so it > is really not needed, however great it might be. No ./configure > options seem to address the problem. Add the line 'GhcWithInterpreter=NO' to your mk/build.mk (create the file if you don't have it). Cheers, Simon

1 0

Re: [Haskell-cafe] Re: Composition of Type Constructors
by Jan Christiansen 30 May '05

30 May '05

On Wednesday 25 May 2005 17:20, Chung-chieh Shan wrote: > Jan Christiansen <jac(a)informatik.uni-kiel.de> wrote in article <Pine.GSO.4.63.0505251243020.11488@arwen> in gmane.comp.lang.haskell.cafe: >> The problem is that I don't know how to express the composition of >> type constructors like the function (.) for ordinary functions. I know >> that (map1 . map2) is wrong but it states what I want to express, >> namely the composition of two type constructors. With this I would >> like to define an instance definition like the following. >> >> >> instance (Mapping map1 key1, Mapping map2 key2) >> => Mapping (map1 . map2) (key1, key2) where >> lookup (key1, key2) = lookup key2 . lookup key1 >> update (key1, key2) f = update key1 (update key2 f) > > You can define the type-level composition yourself. Something like > (untested): > > newtype Comp map1 map2 v = Comp (map1 (map2 v)) > instance (Mapping map1 key1, Mapping map2 key2) > => Mapping (Comp map1 map2) (key1, key2) where > lookup (key1, key2) (Comp map) = lookup key2 (lookup key1 map) > update (key1, key2) f (Comp map) = Comp (update key1 (update key2 f) > map) Thanks. That's a solution. There is no prettier way of doing this, is there. It's not allowed to make an instance of a type synonym and partially applied type synonyms are not allowed anyway. Is there a reason why partial application of type synonyms are forbidden?

2 1

Python?
by Daniel Carrera 27 May '05

27 May '05

Hello, This might be a strange question to ask on a Haskell list, but I do want to hear your opinions. What do you think of Python? To explain where this question is comming from: I have a lady friend who wants to learn how to program. I just decided to teach her Python for practical reasons: 1) Python has a nice IDE-ish thing. It's called "idle". It includes both a shell and an editor. The interface is simple and clear. 2) I can't get Helium to compile (since I can't get ghc to run) on Solaris. 3) Python has some nice introductory documentation. The Haskell documentation is more advanced. 4) She's interested in writing an OOo plugin some day. Python can do that. But I do hesitate. I would like to teach her Haskell because I think it's a better language. But I just don't seem to have the tools to teach it to a complete beginner (idle, documentation). So I'm thinking that perhaps I can use Python, but try to teach her functional principles, like not changing the value of a variable and not letting her functions have side-effects. Given my circunstances, do you think that's a reasonable approach for teaching her how to program? Cheers, Daniel.

19 32

idea's for a 3D modeller in Haskell
by Kenneth Hoste 27 May '05

27 May '05

Hello, I'm planning to start up a project to build a 3D modelling application in Haskell. I don't know which direction I would want to follow, hence this mail. I've set up a small wiki page @ http://haskell.org/hawiki/H3D. I'm looking for neat idea's, existing projects, articles, suggestions, anything that could help me getting in some direction. Currently, I'm considering using L-systems as a base, and maybe use Ogre3D as rendering engine. Feel free to add anything to the wiki or to reply. boegel

1 0

Re: explicit signatures and default for integer literals
by Daniel Fischer 27 May '05

27 May '05

Am Freitag, 27. Mai 2005 15:00 schrieb Mirko Rahn: > Hi all, > > an explicit given signature causes ghc to choose the right types for > integer literals as in > > {-# OPTIONS -fglasgow-exts #-} > > import Data.Map > > f :: Ord a => [a] -> Map a Int > f xs = fromList $ zip xs [0..] > > Here the Literal 0 is threated as (0::Int). > > But the setting > > {-# OPTIONS -fglasgow-exts #-} > > import Data.Map > > class New a b where new :: a -> b > > instance Ord a => New [(a,b)] (Map a b) where new = fromList > > g :: Ord a => [a] -> Map a Int > g xs = new $ zip xs [0..] > > causes the error message > > Could not deduce (New [(a, b)] (Map a Int)) from the context (Ord a) > arising from use of `new' at Why.hs:10:7-9 > > ghc seems to be unable to threat the Literal 0 as (0::Int) this time but > I do not understand why :-( > > Can anyone explain it? > > Thanks, The problem is that ghc can't know that 0 ought to be Int, as it is, nothing prevents you declaring an instance Ord a => New [(a, Double)] (Map a Int) where new = ? and then it's clear that ghc wouldn't know which instance to choose. To solve the problem, I have three suggestions - write [0 :: Int .. ], so ghc knows that New [(a,Int)] (Map a Int) is the required instance - add a fundep: class New a b | [a -> b,] b -> a where ..., and ghc can again deduce the instance - add an expression type signature in 'g' g xs = (new :: Ord a => [(a,Int)] -> Map a Int) $ zip xs [0 .. ] any of these will do, depending on what you want,I recommend one of the first two. Cheers, Daniel

1 0

ghc 6.4 import problem
by Shiqi Cao 27 May '05

27 May '05

Hi, I tried to port some code from ghc 6.2 to ghc 6.4, but I got the following error PrelExts.lhs:41:25: Ambiguous occurrence `map' It could refer to either `GHC.Base.map', imported from Data.List at PrelExts.lhs:11:0-15 or `Data.Set.map', imported from Data.Set at PrelExts.lhs:10:0-14 The following is the first part of the code module PrelExts where import Data.FiniteMap import Data.Set import Data.List import IO There is no problem under ghc 6.2. What should I do? Shiqi Cao

1 0

Re: working Edison, a couple of collection modules, and typing troubles
by oleg＠pobox.com 27 May '05

27 May '05

Samuel Bronson wrote: > I was trying my hand at writing some collection classes myself and I > can't figure out a good typing for map that will let me make Map an > instance of my Collection class... > I don't much like the head of Mapping. How about the following: > class Collection (d k e) (k, e) => Mapping d k e where > -- * Query > lookup :: (Monad m) => k -> d k e -> m e > > instance Ord k => Collection (M.Map k e) (k, e) where > null = M.null > empty = M.empty > <elided> > > instance Ord k => Mapping M.Map k e where > lookup = M.lookup A higher-ranked type constructor gets rid of functional dependencies. The drawback of course is trying to use something like Integer as a mapping from Int to Bool. We have to declare a wrapper > -- Integer as a collection of bits > newtype BitMap k e = BitMap Integer deriving Show > instance Collection (BitMap Int Bool) (Int, Bool) where > empty = BitMap 0 > fromList [] = empty > fromList ((b,v):r) = let BitMap br = (fromList r):: BitMap Int Bool > in BitMap ((if v then setBit else clearBit) br b) > > instance Mapping BitMap Int Bool where > lookup k (BitMap bm) = return $ testBit bm k This actually works (and efficiently: BitMap is a newtype, so no tagging is involved at run-time), but leaves the sense of dissatisfaction. The type BitMap k e appears polymorphic, yet the only permissible values for `k' is Int, and for `e' is Bool. Alas, this facts isn't expressed anywhere. We can add explicit constraints, or better, use GADT: > data BitMap k e where > BitMap :: Integer -> BitMap Int Bool the rest of the code is unchanged.

2 2