- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] Garbage collection and finalizer thread priority
by Simon Marlow 16 Jun '05

16 Jun '05

On 13 June 2005 16:55, Sebastian Sylvan wrote: > On 6/13/05, Simon Marlow <simonmar(a)microsoft.com> wrote: > >> I presume you're running GHC. There's no way to increase the >> priority of a thread - GHC's scheduler doesn't have a concept of >> priorities. >> > > Just out of curiousity, what scheme does GHC use for scheduling > threads? Just round-robin, at the moment. Cheers, Simon

1 0

Annotating calculations
by Rene de Visser 15 Jun '05

15 Jun '05

Hello, I have a somewhat complicated calculation programmed in Haskell. This calculation is coded without using monads. I want to also produce a report describing the details of this calculation for each particular set of inputs. e.g. Number of hours worked = 100. Gross pay per hour = 50. Total gross = 100 * 50 = 500. etc. But about 20 times more complicated than the above. Naturally I need to write functions to produce the above description/report as it should be well presented. Only showing the important parts of the calculation in a sensible order. But I am wondering how to combine the generation of the report with the calculation together. I think if I add the report generating functions into the calculation functions, it will make them twice as messy, and they are already complicated enough. On the other hand replicating the calculation source code twice, once without reporting and once without seems bad. Any suggestions on how to handle this? Rene.

6 7

Documentation of Data.Map
by Shiqi Cao 15 Jun '05

15 Jun '05

Hi, I just read the API of Data.Map and the source code of it. The documentation of "insertWithKey" is not precise. The following is copied from API. *insertWithKey* :: Ord <http://www.haskell.org/ghc/docs/6.4/html/libraries/base/Prelude.html#t%3AOrd> k => (k -> a -> a -> a) -> k -> a -> Map <http://www.haskell.org/ghc/docs/6.4/html/libraries/base/Data.Map.html#t%3AM…> k a -> Map <http://www.haskell.org/ghc/docs/6.4/html/libraries/base/Data.Map.html#t%3AM…> k a /O(log n)/. Insert with a combining function. This function take a function to solve collision, which can be considered as an operator. However the documentation does not specify the order of arguments to the operator. Because of that we can only supply operator which is communitive. But we all know that there must exist an ordering of arguments. I explored the source code of it as the following. -- | /O(log n)/. Insert with a combining function. insertWithKey :: Ord k => (k -> a -> a -> a) -> k -> a -> Map k a -> Map k a insertWithKey f kx x t = case t of Tip -> singleton kx x Bin sy ky y l r -> case compare kx ky of LT -> balance ky y (insertWithKey f kx x l) r GT -> balance ky y l (insertWithKey f kx x r) EQ -> Bin sy ky (f ky x y) l r By the last line the ordering is clear such that the inserted value goes the first. Shiqi Cao

1 0

Trivial question... solve_qe
by Matej 'Yin' Gagyi 15 Jun '05

15 Jun '05

Hi all! I'm new to Haskell... absolutely new. I need some practice, but little problem seems to me like unresolvable... Is there some tutorial of "Exercise, set of resolutions" pairs type? My english is very bat, so there is it in a picture: Exercise 1: hello world Hint: use 'putStrLn' Resolution 1.1 Resolution 1.2 Exercise 2: write functions 'max_num', 'solve_quad_equation', 'reverse_ary' Hint: (Explanation of some technics) Res... Excercise 3: Use do-notation to reverse word in a line read from stdin Hint: Use Exercise 2... (Explain how 'do' works and what to do in common error sitations) So, in a word: I need a tutorial for dummies Now, my current problem is: my program for solving quadratic equation won't compile... import System solve_qe :: Maybe (Double, Double, Double) -> Maybe (Double, Double) solve_qe Nothing = Nothing solve_qe (a, b, c) | d >= 0 = Just ((-b + (sqrt d)) / (2 * a), (-b - (sqrt d)) / (2 * a)) | otherwise = Nothing where d = b^2 - 4*a*c evalArgs :: [String] -> Maybe (Double, Double, Double) evalArgs (a:b:c:[]) = (read a, read b, read c) evalArgs _ = Nothing main = do args <- getArgs print (solve_qe (evalArgs args))

3 2

(**) over integers
by Maurício 15 Jun '05

15 Jun '05

Hi, I'm trying to do this: let f n = mod (n**5) 12 but I see that I can't because ** only operates on floats. Is there an equivalent operator that works on integers? How should I do that? Thanks, Maurício

2 1

RE: [Haskell-cafe] Garbage collection and finalizer thread priority
by Simon Marlow 14 Jun '05

14 Jun '05

On 13 June 2005 11:30, Gracjan Polak wrote: > My space problems continued... :) > > I have some ForeignPtr's, with finalizers (finalizerFree only). And I > have lazyly produced list of those (yes, there is some unsafePerformIO > magic behind, but I think I got this right). The problem is I get > out-of-memory condition because elements get produced faster than > those consumed are garbage collected. > > Example: > > list = ... > mapM_ writeOut list > > writeOut :: Ptr Word8 > writeOut dat = do > hPutBuh handle dat 1024 > -- Control.Concurrent.threadDelay 1000 > > Uncommenting this line allows gc thread to run finalizers, memory gets > freed, everything runs smoothly... > > As far as I know finalizers are run in separate thread. How do I > increase priority of this thread so it runs faster? I presume you're running GHC. There's no way to increase the priority of a thread - GHC's scheduler doesn't have a concept of priorities. I would look into whether you can use mallocForeignPtr: this is much faster than using newForeignPtr with finalizerFree, because the memory is garbage collected directly and there's no need for a finalizer. Cheers, Simon

4 7

Generic types
by Adde 14 Jun '05

14 Jun '05

I'm writing a small unit library to excercise my barely existing Haskell skills. However I can't figure out how to make Haskell accept any type of a specific class. This is what I've got so far: <code> class Unit u where shortName :: u -> String data Meter = Meter instance Unit Meter where shortName u = "m" data UnitValue = UnitValue {uUnit :: Unit u => u, uValue :: Num n => n} </code> Meter is supposed to be a type in the Unit class. UnitValue is supposed to represent unit values regardless of the Unit type. Meter appears to be a subclass of Unit, so far so good: *Units> shortName Meter "m" But I can't get UnitValue to accept Meter as a Unit: *Units> UnitValue Meter 10 <interactive>:1:10: Couldn't match the rigid variable `u' against `Meter' `u' is bound by the polymorphic type `forall u. (Unit u) => u' at <interactive>:1:0-17 Expected type: u Inferred type: Meter In the first argument of `UnitValue', namely `Meter' In the definition of `it': it = UnitValue Meter 10 I strongly suspect that I've got the declaration of UnitValue wrong but I've spent two hours searching the web and trying to get it to work without any success.

3 9

Notes and questions from a first-time Cabal user.
by Brian Smith 13 Jun '05

13 Jun '05

I succeeded in getting my project to build under Cabal. As I converted my makefile to Cabal, I took some notes about things that I found unintuitive, so that the documentation can be improved for future new users. There are some questions mixed in as well. I am using GHC, Cabal, Happy, Alex, and Haddock, all from the CVS head, all built with GHC 6.2.2, all executing under MSYS 1.0's bash 2.04.0(1) on Windows XP Pro SP2. * If I use "Executable: check-ocl2," then under Windows the executable's name really becomes "check-ocl2.exe." This is desireable behavior. But, this causes "Setup.hs copy" and "Setup.hs install" to fail because it tries to copy a file named "check-ocl2" (without the ".exe"), which obviously doesn't exist. How can I get Cabal to generate "check-ocl2.exe" on Windows and "check-ocl2" on all other platforms, and have the "copy" and "install" commands work, without using autoconf? * What is the easiest way to create a "Setup.hs all" command, analogous to "make all" that simply executes "configure." "build," "haddock," and "test" in sequence, stopping on the first failed step? * The tutorial documentation should explain how to use tools like alex and happy. As far as I could tell, the way to do this is to add "Other-Modules: Module.Name.Of.Parser.y Module.Name.Of.Lexer.x" to each executable/library stanza. But, I am not sure why this is necessary, as it seems like it should be able to find them automatically (i.e. without having to list them in the Other-Modules: field) * Is there some way to tell Cabal to generate all intermediate files into a directory that is different than the source directory? I usually keep all my sources in a "src" directory, and then generate all .hi, .o, and .hs files from Happy and Alex into a "build" directory alongside it. This way, my "src" directory only contains stuff that belongs in my version control repository, and "make clean" was simply "rm -Rf build." * If I run "runghc ./Setup.hs" I get this message: No command given (try --help). This is confusing because it isn't clear that it is a cabal error message and not a runghc error message. That is, it isn't clear whether to run "runghc --help" or "runghc Setup.hs --help," and both commands are valid. The message should be improved, or "--help" should be the default command. * Chapter 2 needs to be updated to replace "Hs-Source-Dir" with "Hs-Source-Dirs," since Hs-Source-Dir is deprecated. * It is unintuitive that the examples in chapter 2 use mixed case (e.g. "Hs-Source-Dir") while the program issues error messages using lowercase only ("hs-source-dir"). * Chapter 2 of the documentation states that identifiers can contain underscores. However, Cabal gives "*** Exception: Line 1: Parse of field 'name' failed" if I use "Name: ocl2_haskell" whereas "Name: ocl2haskell" works fine. * Chapter 2 of the documentation states that identifiers must start with a letter. However, "Name: 2" is parsed without complaint. * Chapter 2 of the documentation states that idenfiers must start with a letter. However, "letter" is not defined. Presumably the intention is to restrict identifiers to English letters only? * I originally put my "Build-depends: base" in an "Executable:" stanza. This seems reasonable because presumably different executables (and libraries) could have different dependencies, and it is advantageous to keep track of dependencies on a fine-grained basis. Yet, Cabal requires the Build-depends to be in the main stanza. Why is this? Couldn't Cabal combine all the Build-Depends it finds into the one that it puts into the final package specification? For example, my unit tests require HUnit, but nothing else does. Should I put my unit tests into a seperate package? * The error message for putting "Build-depends: base" in an "Executable: " stanza is: "*** Exception: Line 10: Unknown field 'build-depends' but I think it would be better to say *** Exception: Line 10: field 'build-depends' does not apply to executables or even better: *** Exception: Line 10: field 'build-depends' applies only to the main stanza (and similarly for other fields, e.g. "field 'main-is" applies only to executables") * Chapter 2 of the documentation states that I should be able to use syntax like "foo > 1.2" in Build-depends, but I could not get "HUnit > 1.1" or "HUnit >= 1.1" to work; they fail with parser errors. Regards, Brian

1 0

RE: [Haskell-cafe] [Newbie] Quest for inheritance
by Ralf Lammel 13 Jun '05

13 Jun '05

> On 6/6/05, Gracjan Polak <gracjan(a)acchsh.com> wrote: > > If you stick to single inheritance there is other way to simulate OO in > > Haskell. Look for "phantom types". Whole wxHaskell (for example) is > > based on this concept. > > I heard about them indeed but barely found clear explanations of it. > Any useful pointer you're aware of maybe ? > > Cédric Hi Cedric, See Section 7.3 of the latest revision of "Haskell's overlooked object system". There are pointers and explanations. This discussion also clarifies that the phantom approach is tailored for foreign library and component import (but it can be generalized and has been indeed, by Burton in a paper from 1990). Regards, Ralf

2 1

foldl and space problems
by Gracjan Polak 13 Jun '05

13 Jun '05

Hello, My space problems continued... I have foldl that produces list, some combining function and quite large source list: let xyz = foldl f state myBigList This setting should lazyli consume myBigList when next elements of xyz are demanded. Except that it seems that myBigList is held by state to the end of computation :( Question: is there any way to see what is holding my source list? I did try to guess, but without results as of now:( How do I debug and/or reason about such situation? -- Gracjan

4 6

Generalized version of `words'?
by Dimitry Golubovsky 13 Jun '05

13 Jun '05

Does there exist a generalized version of the `words' function i. e. one that breaks an arbitrary list into parts by an arbitrary predicate? splitAt is not what I need. I had to write my own: -- A version of words, but works with any lists on any predicate. parts pred s = case dropWhile pred s of [] -> [] s' -> w : parts pred s'' where (w, s'') = break pred s' (just by parameterizing `words' found in Data.List with a predicate passed as a parameter). In case such a function already exists, what is its name? In the opposite case, can such a function be added to the standard library? (or why didn't it exist?) Dimitry Golubovsky Middletown, CT

2 2

Garbage collection and finalizer thread priority
by Gracjan Polak 13 Jun '05

13 Jun '05

Hi, My space problems continued... :) I have some ForeignPtr's, with finalizers (finalizerFree only). And I have lazyly produced list of those (yes, there is some unsafePerformIO magic behind, but I think I got this right). The problem is I get out-of-memory condition because elements get produced faster than those consumed are garbage collected. Example: list = ... mapM_ writeOut list writeOut :: Ptr Word8 writeOut dat = do hPutBuh handle dat 1024 -- Control.Concurrent.threadDelay 1000 Uncommenting this line allows gc thread to run finalizers, memory gets freed, everything runs smoothly... As far as I know finalizers are run in separate thread. How do I increase priority of this thread so it runs faster? -- Gracjan

1 0

class Ref...
by Gracjan Polak 13 Jun '05

13 Jun '05

Hi, I the paper of Magnu Carlsson I noticed small, interesting class: class Monad m => Ref m r | m -> r where newRef :: a -> m (r a) readRef :: r a -> m a writeRef :: r a -> a -> m () He defined it locally, but it seems to be very useful generalization of IORef and STRef. Is there something like this in standard libraries? I couldn't find it... :( Is there any reason why isn't it included? Another question: priority queue. In libraries bundled with ghc we have Data.Queue, but I couldn't find PriorityQueue. Is there somewhere an implementation that everybody uses, but is not in the library? Thanks! -- Gracjan

9 13

Control.Monad.Error
by Andrew Pimlott 12 Jun '05

12 Jun '05

I just discovered Control.Monad.Error, and all sorts of questions and ideas came to mind. I would be happy for any comments or pointers. - Monad and MonadError are uncannily similar, especially if you ignore that ugly duckling fail: class (Monad m) => MonadError e m | m -> e where throwError :: e -> m a catchError :: m a -> (e -> m a) -> m a The instances for Either are exactly symmetrical. Is there some more general way to look at this that makes the symmetry stand out? - The instance MonadError IOError IO is problematic, because one might have preferred to use Control.Exception.Exception as the error type. I've been told that the latter is generally preferred, and it's what I usually want. Any chance of the instance being changed? - It's a shame that the utility functions in Control.Exception aren't defined in terms of MonadError. Maybe they should at least be duplicated in Control.Monad.Error. - Why not instance MonadError () Maybe where throwError x = Nothing Nothing `catchError` f = f () Just x `catchError` f = Just x instance Error () where noMsg = () strMsg s = () ? This would seem to facilitate a variation of the "NotJustMaybe" pattern, using MonadError instead of Monad. What I'm getting at is that it might be nice to see MonadError used more in preference to Monad. Then we can get rid of fail. ;-) - I found this function terribly useful: liftError :: (MonadError e m, MonadTrans t, MonadError e (t m)) => m a -> t m a liftError m = join (lift (liftM return m `catchError` (return . throwError))) However, I'm not sure exactly how to describe it (or what to call it--maybe liftTry). It basically pulls errors from the inner monad to the outer monad. One application is try :: MonadError e m => m a -> m (Either e a) try m = runErrorT (liftError m) The really nice thing for me is that I can use it with StateT to prevent errors from disturbing the state, as normally happens when you mix StateT with, say, IO: test1 = execStateT test 0 >>= print where test :: StateT Int IO () test = do put 2 lift (fail "foo") `catchError` \e -> modify (+1) This prints 1, because the IOError obliterates all state changes in the first argument to catchError. However, test2 = execStateT (runErrorT test) 0 >>= print where test :: ErrorT IOError (StateT Int IO) () test = do put 2 liftError (fail "foo") `catchError` \e -> modify (+1) prints 3, because the IOError was caught by liftError, then passed down along with the state change. Oh, and test2 = execStateT (runErrorT test) 0 >>= print where test :: ErrorT IOError (StateT Int IO) () test = do put 2 lift (fail "foo") `catchError` \e -> modify (+1) raises an IOError, because the error is never seen by the outer monad (and catchError). Andrew

1 0

Combining Haskell and Software Verification
by Gerd M 11 Jun '05

11 Jun '05

Hello, I have to do a larger project about Software Verification for university. The methods and systems I've seen so far only concern imperative/OOP languages while there seems to be little concerning functional languages. Since the exact topic can be choosen freely and I've already spent too many years messing around with OOP languages, I would like to do a project related to (or using a) functional language, especially Haskell. The problem is, up to now I wasn't successful in finding it. Suggestions are _very_ welcome! regards, Gerd _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

1 0

CGI module almost useless
by John Goerzen 11 Jun '05

11 Jun '05

My apologies if this sounds like a bit of a rant; I know people put good effort into this, but.... The Network.CGI module in fptools (and GHC) is not very useful. I think that it should be removed or re-tooled. Here are the main problems with it: 1. It does not permit custom generation of output headers. Thus the CGI script cannot do things like set cookies, manage HTTP auth, etc. 2. It does not permit generation of anything other than text/html documents. Many CGI scripts are used to manage other types of documents. Notably this makes it incompatible with serving up even basic things like stylesheets and JPEGs. 3. It does not permit the use of any custom design to serve up HTML, forcing *everything* to go through Text.Html. This makes it impossible to do things like serving up HTML files from disk. 4. There is documentation in the code, but it is as comments only, and doesn't show up in the Haddock-generated GHC library reference. (Should be an easy fix) 5. It does not appear to support file uploads in any sane fashion Is there a better CGI module out there somewhere that I'm missing, or should I just set about writing my own?

9 11

Re: [Haskell] how can i learn haskell?
by Cale Gibbard 10 Jun '05

10 Jun '05

On 10/06/05, mehmet oguz <moguz21(a)hotmail.com> wrote: > Hi, > > I need help all about Haskell. > > How can i study?Which programs i need to write codes? etc. > > Thank you for your attention Though Haskell.org will provide good pointers, I'll try to answer this more directly. There are a number of good resources. One thing which I'd recommend is Hal Daume's "Yet Another Haskell Tutorial" at http://www.isi.edu/~hdaume/htut/ There is an IRC channel, #haskell on irc.freenode.org, where you can come to ask questions and talk about Haskell, and computer science in general. There is also a wiki where you can post questions and read articles on various aspects of the language: http://www.haskell.org/hawiki/ The programs you might want for executing Haskell code include GHC/GHCi at http://www.haskell.or/ghc/. GHC is a full featured Haskell compiler, and GHCi is an interactive interpreter, they come bundled together, and are quite good for most purposes. These are the ones I'd recommend to most people, but there are a few other choices as well. Hugs, at http://www.haskell.org/hugs/ is a fairly popular interpreter written in C, it's faster than GHCi, but the error messages could use some more work in places. There's also NHC, another Haskell compiler, at http://www.haskell.org/nhc98/ which aims at low memory consumption of produced executables. Hope this helps, - Cale

1 0

Re: [Haskell] how can i learn haskell?
by padiolea＠irisa.fr 10 Jun '05

10 Jun '05

go to www.haskell.org You may not be aware of an extraodinary tool called google. Go to www.google.com, type in the box "haskell", click enter, and boom you have got your answer.

1 0

Re: [Haskell-cafe] Looking for lost library
by Samuel Bronson 10 Jun '05

10 Jun '05

On 05/06/05, Dean Herington <heringtonlacey(a)mindspring.com> wrote: > I believe you're describing: > http://portal.acm.org/citation.cfm?doid=581478.581482 . I don't suppose you know of any place to get it *free*?

3 2

A Tool To Show Functions Relationship?
by Dimitry Golubovsky 09 Jun '05

09 Jun '05

Does there exist a tool which given a Haskell source, shows functions that are mutually recursive (i. e. call each other, even via calling third, etc. functions)? Knowledge of that would help to split the module into smaller modules without risk to create recursive modules. For example (slightly artificial, from a parsec-based C syntax parser): declarator = try (do ps <- pointer id <- idd cp <- many cpi return (Declarator ps id cp)) <?> "declarator" idd = try (do s <- anyIdString return (Left s)) <|> try (do tkOp "(" d <- declarator tkOp ")" return (Right d)) <?> "idd" `declarator' and `idd' are mutually recursive, so placing them into different modules would create recursive modules. -- Dimitry Golubovsky Anywhere on the Web

4 3

Re: [Haskell-cafe] A reference manual for the Haskell monad > functions
by Frank-Andre Riess 09 Jun '05

09 Jun '05

> L.S., > > I have written a reference manual for the most common Haskell monad > functions, in the > style of "A Tour of the Haskell Prelude". It can be found at: > http://members.chello.nl/hjgtuyl/tourdemonad.html > > > Known bug: > Not all keywords in the "See also" sections, that could be links, are > links. Nice :) Reading over it once, I noticed that you confused the types of (>>) and (>>=). Didn't see any other mistake, though. Greets, Frank-Andre Riess

2 1

A reference manual for the Haskell monad functions
by Henk-Jan van Tuyl 09 Jun '05

09 Jun '05

L.S., I have written a reference manual for the most common Haskell monad functions, in the style of "A Tour of the Haskell Prelude". It can be found at: http://members.chello.nl/hjgtuyl/tourdemonad.html Known bug: Not all keywords in the "See also" sections, that could be links, are links. -- Met vriendelijke groet, Henk-Jan van Tuyl -- Using Opera's revolutionary e-mail client: https://secure.bmtmicro.com/opera/buy-opera.html?AID=789433

1 0

Space questions about intern and sets
by Gracjan Polak 09 Jun '05

09 Jun '05

Hello all, I've got two questions, both are space related so I'll put them in one e-mail. 1. I'd like to have function intern, that behaves essentially like id, but with the following constraint: if x==y then makeStableName(intern x)==makeStableName(intern y) Reasoning behind this hack: objects equal (as in Eq) should occupy the same place in memory. I've got to parse quite large file, most tokens are the same. Haskell speed is very good, but I constantly run out of memory. Here is something I wrote, but it doesn't work :( intern :: Ord a => a -> a intern x = unsafePerformIO $ internIO x iorefset :: Ord a => IORef(Map.Map a a) iorefset = unsafePerformIO $ do newIORef $ Map.empty {-# NOINLINE iorefset #-} internIO :: Ord a => a -> IO a internIO x = do myset <- readIORef iorefset case Map.lookup x myset of Just y -> do return y Nothing -> do let newset = Map.insert x x myset writeIORef iorefset newset return $ fromJust $ Map.lookup x newset --return x iorefset is re-executed, but it shouldn't. 2. Second question: imagine a Data.Set.Set and Data.Set.map with some function f, that is mostly identity, only some, rare elements are changed. As I understand it, map essentially copies whole structure of set and this leads to out-of-memory conditions for me. So, basically I have space problems. Is there any FAQ out there "how to make my program fit in 256MB of heap?" -- Gracjan

8 12

[Newbie] Quest for inheritance
by Cédric Paternotte 09 Jun '05

09 Jun '05

Hi. This is my first message here so Hello to everyone. I'm just starting to learn Haskell and I really think it's a cool language. Coming from an OO world, I've been looking for ways to achieve inheritance as you get it in Java and the likes. I know OO and inheritance is not really the point of Haskell and that other mechanisms are provided to somewhat achieve reuse. But it's a way of programming I've been so used to that I feel lost without it. You might think I'm heading in the wrong direction. My mistake I have to agree. Let's take it as a learning exercise then. So I've been searching the net for *easy* ways to get it and the least I can say is that I'm confused. It soon became apparent that, inheritance not being a core feature of the language, many people have been hacking Haskell to come up with similar effects (btw I never thought there could be so many ways to reach the same goal...Haskell programmers are clever bastards). Of the many implementations that I've found, few are really simple and most achieve it with various levels of success and/or dodgy syntax. Here are the various techniques I've come across so far : (I'm far from understanding them all) 1. Through existential types As shown in the Shapes example at http://www.angelfire.com/tx4/cus/shapes/haskell.html. However, I couldn't spot the advantage over the standard version using normal classes at http://www.angelfire.com/tx4/cus/shapes/haskell98.html The getX function still needs to be defined in both RectangleInstance and CircleInstance. This is not what I call inheritance. Inheritance would make it possible to define getX only once in ShapeInstance. Or maybe the point was only to demonstrate polymorphism. But then what is the advantage of using existential types ? It just looks like more work compared to the standard version that also makes use of polymorphism. Or am I missing something ? 2. Through typeful heterogeneous collections This technique is described at http://homepages.cwi.nl/~ralf/OOHaskell/ and is able to bring most OO principles into Haskell. This seems to be a very good and thorough attempt. Unfortunately it looks more like a huge hack than a solution. The problem I have with it is the awkward syntax it requires, which to my newbie eyes doesn't look like Haskell anymore. 3. Through phantom types I couldn't find any idiot-proof documentation on this topic but this technique seems to be used to model inheritance. The few papers I've come across (http://research.microsoft.com/Users/simonpj/Papers/oo-haskell/overloading_c… , http://www.informatik.uni-bonn.de/~ralf/publications/Phantom.pdf ,http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf ) seem very interesting but all go way over my head. 4. Through O'Haskell (http://www.cs.chalmers.se/~nordland/ohaskell/) Which is a non standard extension of Haskell that seems to be dead anyway. 5. With this : http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf This is a very interesting paper, at least for a newbie like me who's used to Java. The aim of this paper was to develop a same application in both Java and Haskell and to compare the resulting implementations afterwards. What interested me in this was the mechanism they used to model inheritance (described on page 16 & 19), based on data types instead of classes. The idea being that all constructors of the Employee datatype have a same parameter, 'inCommon', of type 'CommonOfEmployees'. The data type CommonOfEmployees consists of all the fields shared by all types of employees. By then defining polymorphic functions that only use the 'inCommon' property of any employee, they've managed to instantiate these methods only once. My explanation must be horrible to you but you'll certainly get it by reading their paper. The Haskell source code can be found here :http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/Haskell_Impl/ The conclusion I drew from my quick & early findings is that the latest method is the simplest way to get inheritance in my programs. I guess my question now is this : Are there other ways to achieve inheritance in Haskell ? Simpler techniques ? Or more accurate / comprehensive ? Would you have pointers to useful resources ? I apology in advance for the errors, false assertions, misconceptions, confusions made in this document. I'm still learning Haskell. I'd just like to get the most of it. Cedric Paternotte

4 8

OT: http://www.cse.unsw.edu.au host name does not resolve
by Dimitry Golubovsky 09 Jun '05

09 Jun '05

Sorry for this OT, but the server seems to be unaccessible. And so is the Haskell-related stuff on it (like the FFI Addendum). The requested URL could not be retrieved Here's what the proxy says: (possibly a DNS problem) -------------------------------------------------------------------------------- While trying to retrieve the URL: http://www.cse.unsw.edu.au/~chak/haskell/ffi/ The following error was encountered: Unable to determine IP address from host name for unknown server name This means that: The cache was not able to resolve the hostname presented in the URL. Check if the address is correct. -- Dimitry Golubovsky Anywhere on the Web

2 1

Re: [Haskell] Strictness question
by Ben Lippmeier 08 Jun '05

08 Jun '05

>> To gloss over details: it'll reduce x far enough so it knows that >> it's an Integer, but it won't nessesarally compute that integers >> value. > No, Integers don't contain any lazy components. > It statically knows that it's an integer. I meant that it would reduce to the outermost constructor but nessesarally evaluate the rest of the object. Ok, I actually looked up the implementation of Integer in GHC. > -- | Arbitrary-precision integers. > data Integer > = S# Int# -- small integers > #ifndef ILX > | J# Int# ByteArray# -- large integers > #else > | J# Void BigInteger -- .NET big ints You were right and I was wrong, Integers contain no lazy components. Perhaps that just highlights the folly of guessing how much actually gets evaluated in a lazy language.. :) Ben.

1 0

RE: [Haskell-cafe] [Newbie] Quest for inheritance
by Ralf Lammel 07 Jun '05

07 Jun '05

Hi Cedric, > > http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens/ > > Good compromise between complexity, typing and usefulness. [unfortunately also limited, which is the reason that we came up with the monadic version: PoorMens2.] > I noticed that both Rectangle and Circle need to redefine the > operators because of the different names of their respective delegate > to Shape, namely rectangle2shape and circle2shape. > > I we were to give these fields the same name ('parent', or 'super') in > both Rectangle and Circle, could it be that we can avoid to redefine > the operators by moving their definition upwards (and thus requiring > only one definition for both classes) ? Won't work. ;-) Haskell standard records are not polymorphic like this. You can't write an operation that uses a record selector without committing to a specific record type. (With HList that underlies OOHaskell, of course, you can!!!) This is *precisely* the reason that: - Gracjan's code had a get_super. - my code has the generic .?. operator. We could try to give up on using "normal" records. That is, we could use a tuple convention where the first projection returns the data part of the base class, and the second projection returns the contribution of the derivation. However, this won't get us anywhere. We need the nominal types introduced by the new record types in order to represent the inheritance hierarchy in the type system (through the Inherits or Subtype classes). > Would it then be a problem if we further subclass Rectangle in, say, > two subclasses Square and NonSquareRectangle ? Would that still work > or would there be a collision between the multiple 'parent' fields ? Due to the abovementioned reasons, any sort of parent fields will not interfere. Repeated inheritance simply leads to nested data composition; that's Ok. Ralf

1 0

Visual Hashell Studio.NET 2005
by Brian Smith 07 Jun '05

07 Jun '05

Hi, When will VHS support the Visual Studio.NET 2005 Beta? I'd like to volunteer to test VHS.NET 2005 when it is available. (Also, MS is giving away the VS.NET 2005 beta for free, and VS.NET 2003 costs a whopping $15.00 from my school's bookstore). Thanks, Brian

3 3

Infix operators naming conflicts (was: class Ref)
by Dimitry Golubovsky 07 Jun '05

07 Jun '05

Gracjan Polak wrote: > val = readIORef > a=:b = writeIORef a b Pretty shame := is already reserver :(. There is something alike Graphics.Rendering.OpenGL.GL.StateVar. The use $= for assignment. Generalizing "variables" (in respect to some monad) seems to be often reinvented idea :) Indeed, has anyone tried to summarize possible conflicts between infix operators as they are defined in many places to serve different purpose? e. g. (!) :: Ix i => Array i e -> i -> e The value at the given index in an array. (Data.Array) (!) :: a -> [HtmlAttr] -> a (Text.Html) so if a module imports both modules mentioned above simultaneously, will the compiler complain about (!) and ask to use a qualified name? I had the following experience: when trying to create a convenient syntax to access fields of foreign C structures using appropriate Ptr and field label, I tried to define a combinator for that, and to name it (.) (dot, same as dot-composition defined in Prelude, to look similarly to Java notation) Type signature for my (.) was totally different than Prelude's (.), and semantically it is not composition of functions. However the compiler (GHC) asked to use qualified name. Finally I ended up with the name (-->) which looks like C notation. But who knows, whether someone wishes to use (-->) for other purposes? -- Dimitry Golubovsky Anywhere on the Web

2 1

Usage of | in classes
by Frank-Andre Riess 07 Jun '05

07 Jun '05

Hi, Gracjan's question led me to another question: > class Monad m => Ref m r | m -> r where > newRef :: a -> m (r a) > readRef :: r a -> m a > writeRef :: r a -> a -> m () What's the meaning of the bar and the function type in this declaration. I've seen something like that before (with state monads, I think), but couldn't find an explanation in the Haskell grammar (or anywhere else on haskell.org) Thanks in advance, Frank-Andre

2 1

RE: [Haskell-cafe] [Newbie] Quest for inheritance
by Ralf Lammel 07 Jun '05

07 Jun '05

Hi Gracjan, > > http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ > > (again *not* using OOHaskell) > > From the quick skim of code: > .?. -- apply function to upcast object > .!. -- apply modification function to upcast object and substitute > returned value (new object), basically update Absolutely. > Is there any description avaliable what is PoorMens2 all about? Let me try. It's just a variation on Chris' encoding of the shape example, while trying to improve code reuse, while trying to highlight the commonalities in the data parts of the objects in the inheritance hierarchy. The approach ends up being similar to yours in so far that getters (and setters) can be made work for derived types once they are defined on the base type. I just notice that there is a short (because non-monadic) version: http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens/ Ralf

2 1

RE: [Haskell-cafe] [Newbie] Quest for inheritance
by Ralf Lammel 07 Jun '05

07 Jun '05

> Cédric Paternotte wrote: > ... > > > 5. With this : > http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf > > > > Gracjan Polak wrote: > > I've been thinking about slight generalization of this lately. Here are > my semi-backed thoughts as of now. I should have mentioned http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ (again *not* using OOHaskell) The actual example encodes Chris Rathman's shape benchmark. The underlying story is somewhat similar to Gracjan's email. Compared to the code that Gracjan posted, - this code pinpoints another issue of this poormens' approach: get_super is quite obviously not enough if you end up wanting mutable objects. You need a setter as well. (My feeling here is that the encapsulation could be better. It would need coding effort to avoid that all data is public.) - this code also shows how the "fake inheritance through data composition" approach blends with virtual methods: one uses an extra class per abstract/virtual method. (Clearly, one can potentially try to bundle some methods in a class.) An issue here is that client code might get bloated with constraints: for datatype subtyping *and* all used virtual methods. Alternatively, one can place the OO methods (their functional counterparts) in the data capsules themselves! Then you get into the trouble of self references. A more general and preliminary observation: the entire approach is potentially more about object *composition* (and perhaps delegation) rather than inheritance. Many OO evangelists consider inheritance as a concept that was used too much in early OO times, while object composition is often more appropriate and flexible. So one *might* say that this approach does not encode a Java-inheritance solution but it does an inheritance-to-object-composition migration on the fly. So what Gracjan calls "Inherits" (and I call subtyping or substitution) is perhaps more a "delegates". Ralf

3 2

RE: [Haskell-cafe] [Newbie] Quest for inheritance
by Ralf Lammel 07 Jun '05

07 Jun '05

There are tons of good research questions readily waiting. Such as: - What would we want to explore in OOish Haskell so that we, once more, can provide interesting input for mainstream language development? More specifically: what sorts of type inference would make a difference in Java 1.5+, C# 2.0+? - How would Haskell's type-class type system need to evolve in order to provide completely satisfying programmer experience for the uses of type classes in the various existing styles of OOish Haskell programmning? - We have Template Haskell but we are *still* rather lame when doing (OOish) language extensions. Macro systems with syntax extensions perhaps really open up a wormhole but nevertheless: *how* can we get a more experimental Haskell environment where language experiments make a good impression at the level of syntactic sugar, debugging, error messages, and all that? - How is it possible that Haskell lacks true extensible functions (modulo the kind of encoding I sent around earlier)? This is one of the big immediate benefits of OO mainstream programming. Seeing Haskell not providing them, makes me feel sad. It is also amazing that Haskell scores with complicated modes of extensibility (cf. monad transformers), but has no watertight answer when it comes to silly extensible datatypes (or classes) and functions (or methods) defined upon those. - ... Let's go to Sydney :-) (Or at the very least, let's meet at the Haskell Workshop!) Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Matthew Roberts > Sent: Tuesday, June 07, 2005 12:15 AM > To: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] [Newbie] Quest for inheritance > > I don't think this is publishable research, there is too much other > stuff already out there. > > matt > > On 06/06/2005, at 5:58 PM, Gracjan Polak wrote: > > > Matthew Roberts wrote: > >> I have a project (for an early research student) waiting for an > >> interested student to take on. It is called "Programming patterns > >> for OO-like programming in Haskell". The basic idea is to identify > >> how to achieve OO-like organisation of your code in vanilla haskell. > >> Hopefully the student can come to a deep understanding of OO and > >> haskell programming in the process.

1 0

Re: [Haskell-cafe] [Newbie] Quest for inheritance
by Matthew Roberts 07 Jun '05

07 Jun '05

I don't think this is publishable research, there is too much other stuff already out there. matt On 06/06/2005, at 5:58 PM, Gracjan Polak wrote: > Matthew Roberts wrote: >> I have a project (for an early research student) waiting for an >> interested student to take on. It is called "Programming patterns >> for OO-like programming in Haskell". The basic idea is to identify >> how to achieve OO-like organisation of your code in vanilla haskell. >> Hopefully the student can come to a deep understanding of OO and >> haskell programming in the process. > > If this could count as graduate student project and could spawn > publication then I would be interested. :) > >> Sounds like exactly what you need. Shame no-one has taken it up yet. >> Perhaps next semester :) Anyone out there want to come to Sydney >> and take it on? > > As I see you did not cc the list, so currently I'm the only one that > received this message. :) > >> Matt >> On 06/06/2005, at 3:55 AM, Gracjan Polak wrote: >>> Cédric Paternotte wrote: >>> > Hi. This is my first message here so Hello to everyone. >>> > >>> > I'm just starting to learn Haskell and I really think it's a cool >>> language. >>> >>> Me too :) >>> >>> > I know OO and inheritance is not really the point of Haskell and >>> that >>> > other mechanisms are provided to somewhat achieve reuse. But it's a >>> > way of programming I've been so used to that I feel lost without >>> it. >>> > You might think I'm heading in the wrong direction. My mistake I >>> have >>> > to agree. Let's take it as a learning exercise then. >>> >>> Me too :) >>> >>> > 5. With this : >>> http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf >>> > >>> >>> I've been thinking about slight generalization of this lately. Here >>> are my semi-backed thoughts as of now. >>> >>> First of all, in Haskell there will be strict separation between >>> interfaces and data, so almost every method will be declared twice. >>> This is not so strange to anybody programing in Java, but for C++ >>> programmers can be. Inheritance relation is specified after data. >>> There is also separation between two concepts: what interfaces each >>> piece of data implements and which intefaces given interface >>> inherits. So: >>> >>> {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} >>> >>> module Main where >>> >>> -- general inheritance relation >>> class Inherits b x where >>> get_super :: x -> b >>> >>> -- declare interface with one method >>> class IA a where >>> get_a :: a -> Int >>> >>> -- define data with one field >>> data DA = DA { da_field :: Int } >>> >>> -- say how data DA conforms to interface IA >>> instance IA DA where >>> get_a x = da_field x >>> >>> -- declare some other interface IB >>> -- note: IB is unrelated to IA >>> class IB a where >>> get_b :: a -> String >>> >>> -- data that inherits fields of DA and adds one another field >>> data DB = DB { db_super :: DA, db_field :: String } >>> >>> -- DB inherits fields and methods of DA >>> instance Inherits DA DB where >>> get_super x = db_super x >>> >>> -- data DB implements interface IB >>> instance IB DB where >>> get_b x = db_field x >>> >>> -- some other random data >>> data DC = DC { dc_super :: DA } >>> >>> -- DC implements interface IB >>> instance IB DC where >>> get_b x = show (get_a x) >>> >>> -- and inherits DA >>> instance Inherits DA DC where >>> get_super x = dc_super x >>> >>> -- now the tricky part: state that every data x inheriting DA >>> -- implements all interfaces of DA (repeat for each interface) >>> instance (Inherits DA x) => IA x where >>> get_a w = da_field (get_super w) >>> >>> main = do >>> let db = DB (DA 123) "zzz" >>> let dc = DC (DA 123) >>> putStrLn $ show (get_a db) >>> putStrLn $ show (get_a dc) >>> putStrLn $ show (get_b db) >>> putStrLn $ show (get_b dc) >>> >>> As you see there is much more writting as in Java. But this gives >>> better control over inheritance and subsumption because everything >>> must be stated explicitly. Multiple inheritance is allowed :) Also >>> it is "private inheritance" (as in C++) by default. >>> >>> There are some problems left: how to update a field? or how to make >>> inheritance transitive. I don't know it yet :) >>> >>> > >>> > I guess my question now is this : Are there other ways to achieve >>> > inheritance in Haskell ? >>> >>> Me too:) >>> >>> My proposal (above) is about the level of 'OO' things done in >>> procedural languages (example: C with GTK+ library). There must be a >>> better way. Any comments? >>> >>> -- >>> Gracjan >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> > >

1 0

RE: [Haskell-cafe] [Newbie] Quest for inheritance
by Ralf Lammel 07 Jun '05

07 Jun '05

Hi Cedric, Thanks for your investigation. Regarding your guess, the code does *not* use "state monads (for mutable data)". The whole example would make sense without IO. (So this approach is *all* different from OOHaskell :-)) The IO monad is used in Poormens2 because some of the methods might want to do side effects. For instance, in the Shape example, we want to see the progress of drawing at the Console. Also, we added an extra feature to "observe" the invocation of setters. The operators (.?.) and (.!.) can be thought of as generic getters and setters. In fact, close inspection reveals that they rather model reading and writing (or call it object observation and object mutation). Mutability is achieved in Poormens2 merely by having setters. (Optionally, if you like, you *could* use the IO monad to carry around objects. Remember, in OOHaskell, the IO monad provides IORefs for mutable objects; something not used in Poormens2.) (( Some asides: If you remove the IO monad, then the Poormens2 style is really a variation on the style hinted at in Gracjan's email. One interesting difference worth noting is that Gracjan places the actual getters in classes while Poormens2 just uses overloaded functions defined in terms of the generic operators (.!.) and (.?.). But I assert that this is a detail or a minor variation point. There could be monadic and non-monadic versions in the Subtype class; I was just too lazy at that time -- assuming that one needs monads in almost all cases anyhow. (After all, we are trying to understand the migration of imperative OO code to Haskell.) You might say that the fact whether the methods (and getters and setters, say properties) are monadic or not should not disturb the general framework, whereas it does seem to affect the design of the Subtype class used in Poormens2. In particular, you might say that the result type of a getter could be just *any* type: why then expose the monadic status in the framework's types? This is needed for the generic operator (.!.). This operator captures an *in-place* update. That is, it applies the mutator to the supertype component of the datum at hand. Since the aspect of selecting that component *and* putting back the updated component is captured generically, the operator takes a type-preserving function on the supertype and lifts it to a type-preserving function on the subtype. So type preservation is in the type of the generic mutator, and we need the monadic variation on type preservation (i.e., a -> IO a) -- if we anticipate that any mutator will have side effects (in addition to those related to the mutation of the object at hand, which is just explicit in the type!!) It is then just a consistent style to provide a similarly monadic type for generic observers. )) We call this a poor mens' approach because the coding style does not allow for a direct translation of C++/C#/Java OO code -- something we aim to provide by OOHaskell (within limits of course). Ralf > -----Original Message----- > From: Cédric Paternotte [mailto:cpaternotte@gmail.com] > Sent: Monday, June 06, 2005 3:36 PM > To: Ralf Lammel > Cc: haskell-cafe(a)haskell.org; Gracjan Polak > Subject: Re: [Haskell-cafe] [Newbie] Quest for inheritance > > Hi Ralf, > > > I should have mentioned > > http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ > > (again *not* using OOHaskell) > > > > It's been an interesting evening. I've been having a go at your > poormen's source code and, although it's different from OOHaskell, I > still find it very similar in the sense that it's using the same > concepts, namely infix operators (for syntactic sugar I assume) and > state monads (for mutable data). But I had a look at it anyway ;) > > From what I gathered today infix operators are just like ordinary > functions, that differ only in the way you pass them parameters. I > understand the .?. and .!. operators in your code are shortcuts that > apply a function to the parent type, respectively for get and set > operations. > > The only thing I couldn't figure is the reason of using monads. I > noticed they (returnIO) were extensively used in the setters and in > the .!. operator. Do monads provide features without which this whole > thing wouldn't be possible ? What is it exactly they provide in this > context ? > > > A more general and preliminary observation: > > the entire approach is potentially more about > > object *composition* (and perhaps delegation) > > rather than inheritance. > > That's also the way I see it. > > Cédric

1 0

Re: [Haskell-cafe] [Newbie] Quest for inheritance
by ChrisRathman.6155983＠bloglines.com 06 Jun '05

06 Jun '05

--- Cédric Paternotte <cpaternotte(a)gmail.com > Does this mean that I was wrong in saying in my initial post that > existential types can be used to get "code inheritance" ? Or is it > just that the Shapes example has never been meant to illustrate that > side of things ? The Haskell shapes example was a recreational activity that started with Jim Weirich's challenge at: http://onestepback.org/articles/poly/ As Jim notes, inheritance was not the point of the exercise. And the Haskell example I did was somewhere in the middle of 56 other languages I had been tinkering with: http://www.angelfire.com/tx4/cus/shapes/index.html In most of the OOP languages, we tried to use code inheritance if it was available, but where it was not obvious or easily achievable (Erlang, Mercury, Clean, Haskell), it was bypassed. I did spend a bit of time trying to figure out how to get subtype polymorphism to work in Haskell, but in terms of my familiarity with the language, I am by no means proficient with the language. Best to ask Ralf about the more involed stuff. :-) > Okay, I think I've finally spotted the difference : Using existential > types you actually managed to put both CircleInstance and > RectangleInstance in the same list. I didn't notice that detail at > first. All the difference lies in that line ;) Subtypes may share some common behavior but from a top level perspective, a Rectangle type is not the same as a Circle type. Existential types allow you to treat the different types via the common behavior defined in the parent type. Without existential types, you can have only monomorphic collections. Chris Rathman

1 0

Re: [Haskell-cafe] [Newbie] Quest for inheritance
by ChrisRathman.6155983＠bloglines.com 06 Jun '05

06 Jun '05

The differences in the two shape examples doesn't have to do with code inheritance - it has to do with subtype polymorphism. Existential types allow you to throw different subtypes into a collection and have the function dispatch on the common superclass type. The example without existential types demonstrates parametric polymorphism, but not subclass polymorphism. Generally speaking, OO programming is based on three properties (a) encapsulation; (b) inheritance; and (c) polymorphism. Well, Haskell has pretty good means of encapsulation (though I'm spoiled by ML at the moment). And existential types can get you subtype polymorphism. As far as inheritance, there's actually two kinds that occur in most OO languages. The first being type inheritance (which really just gets you subtype polymorphism). And then there's code inheritance - which is what you are trying to achieve. A language like Sather actually treats type inheritance and code inheritance as seperate things. Languages that mix the two concepts have their own set of difficulties, as the two forms of inheritance are sometimes at odds with each other. Anyhow, the classic case for code inheritance is from a re-use perspective - i.e. not having to repeat the code in multiple places. The classic problem with code inheritance is that it breaks encapsulation, as classes that reuse code from a superclass become tightly coupled with the implementation. At any rate, I consider inheritance to be a convenience mechanism, and not vitally necessary to the concepts of encapsulation, type inheritance, and polymorphism, though I realize that many do consider it important. From a Java perspective, you usually have to decide whether you want single inheritance via class extension, or multiple inheritance via interface implementation. >From the perspective of Java, the shape example that does not have code inheritance corresponds to the Java world of Interfaces - with Interfaces not allowing code inheritance. Chris Rathman --- Cédric Paternotte <cpaternotte(a)gmail.com wrote: > 1. Through existential types > > As shown in the Shapes example at > http://www.angelfire.com/tx4/cus/shapes/haskell.html. > However, I couldn't spot the advantage over the standard version using > normal classes at > http://www.angelfire.com/tx4/cus/shapes/haskell98.html > > The getX function still needs to be defined in both RectangleInstance > and CircleInstance. This is not what I call inheritance. Inheritance > would make it possible to define getX only once in ShapeInstance. Or > maybe the point was only to demonstrate polymorphism. But then what is > the advantage of using existential types ? It just looks like more > work compared to the standard version that also makes use of > polymorphism. Or am I missing something ?

2 1

RE: [Haskell-cafe] [Newbie] Quest for inheritance
by Ralf Lammel 06 Jun '05

06 Jun '05

Re: your enumeration. Let me add one more bullet. In cases where inheritance is about abstract base classes and concrete subclasses ((add interface polymorphism likewise)) you can use a (for unknown reasons) unappreciated pattern for extensible datatypes in Haskell: http://homepages.cwi.nl/~ralf/OOHaskell/src/interpreter/extensible.hs (Note: conceptually unrelated to OOHaskell) Re: OOHaskell Thanks for calling this a very good and thorough attempt :-) I would really like to understand why you think that a) this could possibly be a "huge hack" b) "awkward syntax" would be involved. Regarding a), could it be that you are overwhelmed by the details of the implementation of OOHaskell' *typeful* object system? Wouldn't you be similarly concerned when looking at details of *any* other object system of *any* other *typed* language? (( We are currently massaging the OOHaskell paper. >From what you say, it might seem appropriate to emphasize the OO programming API more clearly, while moving implementation details of OOHaskell out of the face of a programmer who migrates from C#/Java to Haskell. )) Regarding b), could it be that you would want to see special keywords in your face, rather than thinking in terms of records, monadic functions, open fixpoints, closing fixpoints, ...? If yes, I guess that's an valid desire. If there was a mainstream technique for Haskell syntax extension, we want to use it for OOHaskell. Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Cédric Paternotte > Sent: Sunday, June 05, 2005 6:52 AM > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] [Newbie] Quest for inheritance > > Hi. This is my first message here so Hello to everyone. > > I'm just starting to learn Haskell and I really think it's a cool > language. > > Coming from an OO world, I've been looking for ways to achieve > inheritance as you get it in Java and the likes. > > I know OO and inheritance is not really the point of Haskell and that > other mechanisms are provided to somewhat achieve reuse. But it's a > way of programming I've been so used to that I feel lost without it. > You might think I'm heading in the wrong direction. My mistake I have > to agree. Let's take it as a learning exercise then. > > So I've been searching the net for *easy* ways to get it and the least > I can say is that I'm confused. It soon became apparent that, > inheritance not being a core feature of the language, many people have > been hacking Haskell to come up with similar effects (btw I never > thought there could be so many ways to reach the same goal...Haskell > programmers are clever bastards). Of the many implementations that > I've found, few are really simple and most achieve it with various > levels of success and/or dodgy syntax. > > Here are the various techniques I've come across so far : > (I'm far from understanding them all) > > 1. Through existential types > > As shown in the Shapes example at > http://www.angelfire.com/tx4/cus/shapes/haskell.html. > However, I couldn't spot the advantage over the standard version using > normal classes at > http://www.angelfire.com/tx4/cus/shapes/haskell98.html > > The getX function still needs to be defined in both RectangleInstance > and CircleInstance. This is not what I call inheritance. Inheritance > would make it possible to define getX only once in ShapeInstance. Or > maybe the point was only to demonstrate polymorphism. But then what is > the advantage of using existential types ? It just looks like more > work compared to the standard version that also makes use of > polymorphism. Or am I missing something ? > > 2. Through typeful heterogeneous collections > > This technique is described at > http://homepages.cwi.nl/~ralf/OOHaskell/ and is able to bring most OO > principles into Haskell. This seems to be a very good and thorough > attempt. Unfortunately it looks more like a huge hack than a solution. > The problem I have with it is the awkward syntax it requires, which to > my newbie eyes doesn't look like Haskell anymore. > > 3. Through phantom types > > I couldn't find any idiot-proof documentation on this topic but this > technique seems to be used to model inheritance. The few papers I've > come across (http://research.microsoft.com/Users/simonpj/Papers/oo- > haskell/overloading_conf.pdf > , > http://www.informatik.uni-bonn.de/~ralf/publications/Phantom.pdf > ,http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf ) seem > very interesting but all go way over my head. > > 4. Through O'Haskell (http://www.cs.chalmers.se/~nordland/ohaskell/) > > Which is a non standard extension of Haskell that seems to be dead anyway. > > 5. With this : http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01- > 60.pdf > > This is a very interesting paper, at least for a newbie like me who's > used to Java. > The aim of this paper was to develop a same application in both Java > and Haskell and to compare the resulting implementations afterwards. > > What interested me in this was the mechanism they used to model > inheritance (described on page 16 & 19), based on data types instead > of classes. The idea being that all constructors of the Employee > datatype have a same parameter, 'inCommon', of type > 'CommonOfEmployees'. > The data type CommonOfEmployees consists of all the fields shared by > all types of employees. By then defining polymorphic functions that > only use the 'inCommon' property of any employee, they've managed to > instantiate these methods only once. My explanation must be horrible > to you but you'll certainly get it by reading their paper. > The Haskell source code can be found here > :http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/Haskell_Impl/ > > The conclusion I drew from my quick & early findings is that the > latest method is the simplest way to get inheritance in my programs. > > I guess my question now is this : Are there other ways to achieve > inheritance in Haskell ? > Simpler techniques ? Or more accurate / comprehensive ? Would you have > pointers to useful resources ? > > I apology in advance for the errors, false assertions, misconceptions, > confusions made in this document. I'm still learning Haskell. I'd just > like to get the most of it. > > > Cedric Paternotte > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Looking for lost library
by Gracjan Polak 06 Jun '05

06 Jun '05

Hi, Sorry for stupid question, but... Some time ago I read a beautiful paper about variables that had their dependencies automatically tracked and could trigger recalculation when changed. Prototype was implemented in OCaml, then reimplemented in Haskell (using monads). I would like to read that paper once again, but... I lost it :( I do not remember neither title, nor authors. Google asked about any keywords that come to my mind do not show any interesting results. So I ask here :) Can anybody help me, please? Thanks for any pointers... -- Gracjan

2 2

RE: [Haskell-cafe] Re: CGI module almost useless
by Simon Marlow 05 Jun '05

05 Jun '05

On 03 June 2005 14:17, John Goerzen wrote: > On 2005-06-02, Ferenc Wagner <wferi(a)tba.elte.hu> wrote: >> Yes, I also mailed upstream and got no response. But I'm >> using WASH under GHC 6.4 without any problems. Automatic >> preprocessor invocation is not supported in 6.4, but that >> style of coding didn't really work out for me anyway. > > Can you enlighten us as to how you made that work? > > I built and installed WashNGo 2.3.1 using the patch at > http://article.gmane.org/gmane.comp.lang.haskell.libraries/3160 for > GHC > 6.4. > > When I try to build a particular program that uses it, I get this: > > /usr/local/lib/WASH-CGI-1.4.37/ghc-6-4/import/Fields.hi : > Could not find module `ISO8601': > it is not a module in the current program, or in any known > package. ghc-6.4: panic! (the `impossible' happened, GHC version 6.4): > forkM Declaration for zdfReasonISODate{v} That error message is most likely caused by missing modules in the package specification. That is, there are modules missing from either the 'exposed-modules' or 'hidden-modules' field of the package spec (or .cabal file, if you're using Cabal). Cheers, Simon

1 0

About ($)
by Frank-Andre Riess 05 Jun '05

05 Jun '05

Hello there, name's Frank-Andre Riess. Nice to meet you m(_ _)m So, well, my first question on this list is admittedly somewhat simple, but I managed to delay it long enough and now I think I should ask about it: Does ($) have any relevance at all except for being a somewhat handier version of parentheses? Thanks in advance for taking the time to enlighten me. Regards, FAR

5 4

Processing a file with HaXml without invoking processXmlWith?
by Echo Nolan 02 Jun '05

02 Jun '05

Hi all, I've an application which needs to process some XML, but the only way I can see in the Haddock-generated documentation is using the processXmlWith wrapper, which reads it's input and output arguments from the command line. I'd prefer a pure function which took a Document or a String and returned the same, processed. I hope I've overlooked something. Regards, Echo Nolan

4 4

LC online references
by Matthew Roberts 02 Jun '05

02 Jun '05

Hi, I hope I am not too OT here. I am in the process to coming to terms with various calculi based on the lambda calculus. I end up returning to LC books all the time to put things in context. However, I have taken to living out of my laptop and certainly can't carry around the laptop, the book I am reading plus Barendregt's book (plus my phone, plus ....). Besides, I can't afford to buy any books and the library is going to want it back sometime. Does anyone have any pointers to useful online references for the LC? Matt

2 1

RE: Re[2]: [Haskell-cafe] ghc 6.4 import problem
by Simon Marlow 02 Jun '05

02 Jun '05

On 01 June 2005 07:24, Bulat Ziganshin wrote: > Hello Fergus, > > Tuesday, May 31, 2005, 10:24:41 PM, you wrote: > >>> import Data.Set hiding (map) >>> import qualified Data.Set as Set >>> >>> will do fine. > >> That code only compiles with ghc 6.4, and won't compile with ghc 6.2: >> you'll get an error for the "hiding (map)" part, because in 6.2 >> Data.Set does not contain a "map" function. > > btw, question to Simon Marlow and Simon PJ - how about disabling this > error message? You mean allowing import M hiding (x) even if x is not exported by M? Or making it a warning? That's certainly possible, but it constitutes an extension to Haskell 98, so it would at least require the -fglasgow-exts flag. I think you're better off keeping your code portable. Cheers, Simon

2 1

G machine in FORTH
by Andrew Harris 02 Jun '05

02 Jun '05

Hi - Brace yourself... I work in an environment where FORTH is still used. I've been thinking about writing a G-machine interpreter in FORTH so that one could write Haskell like programs that would compile down and run "graph-reduction" style on the FORTH machine. Many developers think FORTH is nice, but the language is so, shall we say, "terse". I'm curious about what people think about this; having the expressiveness of a Haskell-like language that compiles to this environment might provide the best of both worlds, simple hardware architecture and an advanced programming language. let me know what you think, -andrew

5 4

Type extensions
by Thomas Davie 02 Jun '05

02 Jun '05

Hi, I was wondering if I hat missed something and it was possible to do this within the Haskell type system or not... Essentially I would like some sort of inderritance property for Haskell types, I often find myself wanting to for example extend a tree with black/white colouring, or later extend the tree with some sort of ID, etc. So I would eno up with three data types data MyTree = Branch MyTree MyTree | Leaf type BwTag = Bool data MyBwTree = Branch BwTag MyBwTree MyBwTree | Node BwTag data MyBwTaggedTree = Branch BwTag Int MyBwTaggedTree MyBwTaggedTree | Node BwTag Int and several functions to move from one to another. (Or define the most complex and not always use all the attrdbutes). What I would prefer is to be able to spocify something like: data MyTree = Branch MyTree MyTree | Leaf type BwTag = Bool data MyBwTree extends MyTree with BwTag=True data MyBwTaggedTree extends MyBwTree with Int=0 Specifying that myBwTree is the same as MyTree but with an extra argument on each node, and to generate functions to translate between them that fill in True as a default value for the extra tag. Is this possible? Thanks Tom Davie

3 4

Wash broken with GHC 6.4
by John Goerzen 01 Jun '05

01 Jun '05

Hi, I'm trying to use Wash with GHC 6.4. I have applied the patch from http://article.gmane.org/gmane.comp.lang.haskell.libraries/3160, and now it at least compiles. However, despite using -package WASH -package WASH-CGI -package WASHHTML, ghc is not automatically sending the input files through wash2hs. GHC 6.2 did this. Incidentally, is Wash dead upstream? I am surprised that there is no upstream version yet that even tries to work with GHC 6.4. -- John

1 0

ghc 6.4 import problem
by Shiqi Cao 01 Jun '05

01 Jun '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

7 7

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