March 2006 - Haskell-Cafe

Moving from Hugs to GHC and getting an error
by Adam Wyner 31 Mar '06

31 Mar '06

I developed some code in Hugs, but now am moving to GHC. I had used Hugs because I wanted to use the Trex module (extensible records), but this has not been as important as I had thought it would be. My modules run fine in Hugs, but I get an error message when I try to run my module in GHC. The message is: parse error on input `PropList' Otherwise the imported modules are interpreted. In the module, the type declarations are: type PropList = [String] type World = Int type Time = Int type SOA = Rec (properties :: PropList, time :: Time, world :: World) type DBSoas = [SOA] The error occurs just after PropList. Is there some basic difference between Hugs and GHC that I'm missing? Where can I get more information about Hugs GHC differences? Cheers, Adam

2 1

Newbie question: inferred type
by David Laffin 31 Mar '06

31 Mar '06

Hi, Newbie question. Given the inferred type for square, the inferred types for quad1, quad2 and quad3 are what I would expect. Is there a straightforward explanation (i.e. one that a newbie would understand) as to why the inferred type for quad4 is less general? Regards, dl -- GHC Interactive, version 6.4, for Haskell 98. Prelude> let square x = x * x Prelude> :t square square :: (Num a) => a -> a Prelude> let quad1 x = square (square x) Prelude> :t quad1 quad1 :: (Num a) => a -> a Prelude> let quad2 x = square $ square x Prelude> :t quad2 quad2 :: (Num a) => a -> a Prelude> let quad3 x = (square . square) x Prelude> :t quad3 quad3 :: (Num a) => a -> a Prelude> let quad4 = square . square Prelude> :t quad4 quad4 :: Integer -> Integer ___________________________________________________________ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com

3 2

multiple computations, same input
by Greg Fitzgerald 31 Mar '06

31 Mar '06

How do I perform multiple computations on a long lazy list without introducing a space leak? Doing a single computation like this works great: f = show . filter (> 1) But if I do something like this: f lst = show (filter (> 1) lst, filter (> 2) lst) then it looks like GHC won't garbage collect list elements until the first filter has completely finished, and the second filter has iterated over them. Is there an easy way to feed each element into both functions, instead of feeding all elements to one function, and then all to the next? Thanks, Greg

11 20

Wrapping the IO monad to get safe, self-describing imperative APIs
by Brian Hulley 30 Mar '06

30 Mar '06

Hi - In a discussion started on the GHC mailing list http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009923.h… I discovered an idea for typing imperative API functions that may be of interest to other people, and which makes use of Haskell's type system to achieve a level of self-description and static bad-usage detection impossible in C/C++ APIs. A nicely formatted (by trac) description of the advantages and how to write such APIs is available at http://hackage.haskell.org/trac/ghc/ticket/736 (a feature request I submitted to the GHC team to make it easier to write such APIs) and the plain text is included at the end of this post. The basic idea is that different monads, which are just newtypes of the IO monad, can be used to prevent API functions being called in the wrong context. For example, consider the following C function which implements a render callback using a simplified version of DirectX to draw a square on the screen: void Render(int width, int height){ Clear(); BeginScene(); DrawSquare(); EndScene(); } In the C code, the fact that DrawSquare() can only be called between Begin/EndScene, and the fact that Clear(), BeginScene(), EndScene() can only be called in a render callback (as opposed to a keypress callback for example) are completely implicit, and must be borne in mind by the user who has to wade through heaps of documentation to guess at this understanding. By using different monads in Haskell, the above function could be written as follows: newtype RenderM a = RenderM (IO a) deriving (Functor, Monad, MonadIO) newtype DrawM a = DrawM (IO a) deriving (Functor, Monad, MonadIO) type RenderCallback = Int -> Int -> RenderM () onRender :: RenderCallback -> IO () clear :: RenderM () scene :: DrawM () -> RenderM () drawSquare :: DrawM () render :: RenderCallback render w h = do clear scene $ do drawSquare making it impossible to call drawSquare in any situation that the API did not intend, and also making it easy to see that in order to draw something, the drawing will need to be an argument of some function which makes use of DrawM () eg scene, which in turn needs to be an arg of some function which takes a RenderM () thus leading from inside out: drawSquare --> scene --> RenderCallback --> onRender. A consequence of all this is that it would be necessary (to completey enforce API correct usage) to have an extra optional entry point for Haskell programs, to prevent APIs being re-started by lifting their init functions into a callback monad (more details at the end of this post and the trac report). Regards, Brian. #736: Allowing any newtype of the IO monad to be used in FFI and extra optional entry point ------------------------------------+--------------------------------------- Reporter: brianh(a)metamilk.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.4.1 Severity: normal | Keywords: FFI foreign monad entry point Os: Multiple | Difficulty: Unknown Architecture: Multiple | ------------------------------------+--------------------------------------- Hi - When designing an API it is desirable to be able to encode the correct usage patterns for functions in the API in the type of the functions themselves, rather than relying on the user understanding the documentation and having to use runtime checks to ensure correct usage. Consider the following callback which uses a typical C API (DirectX) to draw something to the screen: {{{ void Render(int width, int height){ Clear(); BeginScene(); DrawSquare(); EndScene(); } }}} In Haskell with the FFI at present, we can define an equivalent API and use it as follows: {{{ type RenderCallback = Int -> Int -> IO () clear :: IO () scene :: IO () -> IO () drawSquare :: IO () onRender :: RenderCallback -> IO () runGraphicsWindow :: IO () -> IO () render :: RenderCallback render w h = do clear scene $ do drawSquare main = runGraphicsWindow $ do onRender render }}} This is all very well, but just like the C equivalent, it doesn't encode the fact that drawSquare can only be called between BeginScene and EndScene. For example the following render callback would result in a runtime error or at least an unexpected result for the user: {{{ badRender w h = drawSquare }}} To allow the type checker to enforce correct usage, we can use different monads which just wrap the IO monad as follows: {{{ newtype RenderM a = RenderM (IO a) deriving (Functor, Monad, MonadIO) newtype DrawM a = DrawM (IO a) deriving (Functor, Monad, MonadIO) type RenderCallback = Int -> Int -> RenderM () clear :: RenderM () scene :: DrawM () -> RenderM () drawSquare :: DrawM () }}} Now the good render function is well typed and the badRender function is ill typed. With the current GHC implementation, it is possible to provide the interface above by using some fiddly wrapper functions to remove the wrapper monads and replace them with the IO monad, for example: {{{ type RenderCallbackIO = Int -> Int -> IO () foreign import ccall "wrapper" mkRenderCallbackIO :: RenderCallbackIO -> IO (FunPtr RenderCallbackIO) dropRenderM :: RenderCallback -> RenderCallbackIO dropRenderM f x y = let RenderM io = f x y in io foreign import ccall api_onRender :: FunPtr RenderCallbackIO -> IO () onRender :: RenderCallback -> IO () onRender f = mkRenderCallbackIO (dropRenderM f) >>= api_onRender foreign import ccall api_clear :: IO () clear :: RenderM () clear = liftIO $ api_clear }}} As far as I can tell, GHC currently optimizes out all the overhead involved in converting between RenderM and IO. However the extra marshalling functions are fiddly to write, in particular since different versions of dropRenderM would be needed for different numbers of arguments in whatever function returns something in RenderM, and all these extra functions also obscure the simplicity of the original design. Therefore I propose that for any monad M defined by: {{{ newtype M a = M (IO a) deriving (Functor, Monad, MonadIO) }}} M a should be able to appear in place of IO a anywhere in a foreign function definition since all 'M' does is to enforce typing on the Haskell side and has no relevance to the foreign language API, just as IO has no relevance to the foreign language either. This would mean we'd no longer have to write extra wrapper functions and rely on the compiler optimizing them out. A related point is that the "API-safety == type correctness" gained by using different monads can at the moment be subverted because the entry point into a Haskell program is the main function which returns a value of type IO (). This means that initialization code for any API must be able to run in the IO monad. However every monad discussed above allows you to lift IO operations into it, so there is nothing to stop someone trying to make a nested re-initialization of the API in the middle of a callback... It is necessary to allow IO actions to be lifted into the callback monads so the callbacks can make use of IORefs etc. However it is undesirable to allow the API to be re-initialized (in such a nested way). Therefore I propose (perhaps this should have been a separate ticket but I don't know how to link two tickets together so I've bundled both issues in this ticket) that there should be an alternative entry point into a Haskell program with the following type: {{{ newtype MainM a = MainM (IO a) deriving (Functor, Monad, MonadIO) _main :: MainM () }}} with this default implementation: {{{ _main = liftIO $ main }}} so that all existing programs will still work. If _main is explicitly defined by the user, the user's definition should be used instead, and any definition of "main" will have no special significance. This would allow the API's initialization function to be safely typed as: {{{ runGraphicsWindow :: IO () -> MainM () _main = runGraphicsWindow $ do onRender render }}} Thus the user would be prevented from making nested calls to the initialization function.

1 0

List of instantiated types
by Mirko Rahn 30 Mar '06

30 Mar '06

Hello, please suppose the following setting: (see [1] too) {-# OPTIONS_GHC -fglasgow-exts #-} module C where class C a where name :: a -> String ; pre :: a -> a data Cs = forall a . (C a) => Cs a instance C Cs where name (Cs a) = name a ; pre (Cs a) = Cs (pre a) mkCs :: C a => a -> Cs mkCs = Cs instance C Int where name = show ; pre = \ _ -> 0 instance C Char where name = return ; pre = \ _ -> 'A' all_Cs = [ mkCs (undefined :: Int), mkCs (undefined :: Char) ] Note that despite I served undefined values only I can type *C> map (name . pre) all_Cs ["0","A"] to extract some information. But, when several instances spreads over some modules, writing down 'all_Cs' is an error-prone task, in particular when using some third party modules. So my question is: Is it possible to construct 'all_Cs' automatically? I think such a list cannot be constructed at compile-time, but at link- and run-time a complete list of instantiated types should be available. But is this list accessible somehow? Is there a possibility to write foreach type t that is an instance of C: return (mkCs (undefined :: t)) What is the general problem? Thanks, MR [1] http://www.haskell.org/pipermail/haskell-cafe/2006-March/014947.html -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

2 1

Haskell saves lives :)
by Bulat Ziganshin 30 Mar '06

30 Mar '06

-- i think that this may be interesting for other haskellers Hello Wolfgang, Wednesday, March 29, 2006, 8:24:09 PM, you wrote: >> so, the concurrent programming, may be, the only area at now, where >> real-world, commercial programmers should prefer Haskell over all >> other languages. > are you a real-world, commercial programmer? If yes, I'd like to know the yes > reason(s) for you programming in Haskell. Was it Haskell's support of > concurrency? Just interested… 1. i don't write commercial apps with Haskell. although it's not entirely impossible. i've written in cafe (search for subject "Haskell's market") that i think about this now 2. programming languages is my hobby. in my feeling the main problem with C++ and Delphi (i don't used Java/C#) is that working with complex datatypes is not simple and straightforward, another problem is lack of support for anonymous code blocks (closures). even Perl beats them in these areas! Haskell attracted me due to the great type system, great closures support, type inferencing, good syntax. Having the full power of functional language to write most complex parts of code (i mean they require most complex algorithms) is very helpful. at the same time, for 80% of program speed is not matter, and FP/laziness again helps here, allowing just to write faster these parts of program. in addition, Haskell is very strong-typed language what allows to catch much more errors at compile time. these all results in what i wrote in less than one year program that is close in functionality to that others wrote in C++ during several years. this program required to write several general purpose libs and bindings to C libs, so i enlarged HCAR's hall of fame with some new entries :) about Concurrency - i was amazed how easy to use it. my first experience in this area was carrying out part of algorithm to another thread and it was implemented with just about 30-40 lines of code! i then enclosed this technique in the module that allows to use threads as message-processing systems - each has an "stdin", "stdout" and so on and there are functions that can create networks of arbitrary complexity from individual threads. again, the Haskell's type system greatly helps me here, allowing to pass between threads structured values of arbitrary types instead of just bytes - i can't imagine whether i will have enough patience to express in another language requirement that "stdout" of each thread should produce values of exact the same type as accepted by "stdin" of next thread in the pipe/network. again, Haskell saves lives :) - i mean that its powerful type system and type inferencing allowed to write type-safe code in the area where any other language would fail. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Re: Equirecursive types?
by lee marks 29 Mar '06

29 Mar '06

John Hughes wrote: > ... > > > Indeed, error messages in common cases would be worsened significantly, > because as Ross says, common errors (such as forgetting a parameter in a > recursive call) would lead to legal definitions that cause a type error > when applied. Partly for this reason, OCaml permits recursion only in > object types, if I remember rightly, where it's most useful. In other > cases the occurs check is still used. > Couldn't this be mitigated by requiring an explicit type annotation on the function being called recursively? In other words infinite types are never silently inferred, but can only coincide with explicit signatures. So this is legal: type Fix s a = s a (Fix s a) fold :: Functor (s a) => (s a b -> b) -> Fix s a -> b fold f = f . fmap (fold f) but this is not: fold f = f . fmap (fold f) I guess it just seems that banning infinite types altogether is throwing the baby with the bath. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

haskell programming guidelines
by Christian Maeder 28 Mar '06

28 Mar '06

Hi, haskell admits many programming styles and I find it important that several developers of a prject agree on a certain style to ease code review. I've set up guidelines (still as plain text) for our (hets) project in http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… These were inspired by C programming guidelines, http://haskell.org/hawiki/ThingsToAvoid and the problems I came across myself. It like to get comments or proposals for our or other haskell grogramming guidelines. Thanks Christian

10 31

planet.haskell.org? for Haskell blogs
by Isaac Jones 28 Mar '06

28 Mar '06

I think someone should volunteer to set up "Planet Haskell" ala Planet Debian, Planet Gnome, Planet Perl, etc. These sites are "Blog aggregators". Basically they just collect the RSS feeds of the community and post their blogs to a web page in a cute format (the gnome one is especially cute, but you probably could have guessed that). There's already software out there for this, so nothing new needs to be written. I think we need a volunteer to set this up somewhere? Preferably someone with their own server, and we'll worry about setting up the DNS later :) peace, isaac See: http://planet.debian.org/ http://planet.gnome.org/ http://planet.perl.org/

3 9

Defining instance needs allow-undecidable-instance?
by Daniel McAllansmith 28 Mar '06

28 Mar '06

Hi, folks. I've got a working class and instances thereof. I would now like to change the class such that error behaviour is specified by MonadError, for the moment throwing String errors. When I try to add MonadError into the types I eventually hit the requirement for allow-undecidable-instances. Is there some way I can I avoid having to use this extension? My starting point consists of: class (Num i, Bounded i, Monad m) => MonadSource i m | m -> i where ... newtype SourceT i m a = SourceT (StateT (Store i) m a) deriving (Functor, Monad, MonadIO, MonadTrans) instance (Num i, Bounded i, Monad m) => MonadSource i (SourceT i m) where ... I changed it to: class (Num i, Bounded i, Monad m, MonadError String m) => MonadSource i m | m -> i where .... newtype SourceT i m a = SourceT (StateT (Store i) m a) deriving (Functor, Monad, MonadIO, MonadTrans, MonadError e) instance (Num i, Bounded i, Monad m, MonadError String m) => MonadSource i (SourceT i m) where ... Thanks Daniel

2 2