June 2005 - Haskell-Cafe

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 08 Jun '05

08 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 07 Jun '05

07 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