- Haskell-Cafe - Haskell.org

MonadGL - Partitioning effects without giving up type inference
by Jules Bean 14 Sep '07

14 Sep '07

The OpenGL bindings which come bundled with ghc are a really great example of how even an "almost-literal" port of a C API can still be easier to work with in haskell than it is in C, because of the benefits of type inference and powerful abstractions. Even the ability to mapM_ is a tool to make C programmers envious, and there are useful combinators like preservingMatrix to guarantee pairing of pushes and pops. Because the bindings are ported over using the FFI, all the GL calls are in the IO monad. GL is build around state machines, so it's not at all surprising to end up in some kind of state monad. However, we find that the type system is not powerful enough to distinguish between myActionWhichOnlyMakesGLCalls :: IO () and myActionWhichMixesGLAndIO :: IO () It would be much nicer if the type-system could distinguish the two. One case in point is that an arbitrary IO action can modify IORefs, and it would be nice to have actions whose type guaranteed that they didn't do that. It's fairly simple to imagine something like the following: > {-# OPTIONS -fglasgow-exts #-} (extensions are only for deriving (Monad), it's not important) > > newtype GL a = GL { runGL :: IO a } deriving (Monad) > > unsafeIOToGL :: IO a -> GL a > unsafeIOToGL = GL The intention here of course is that we export 'runGL' which is safe, having type GL a -> IO a, but don't export unsafeIOToGL. Then we have lots of functions which are imported via the FFI and end up with IO types, here is a trival example: > _foo :: IO () > _foo = putStrLn "OpenGL!" And we embed them into the GL monad. No other module can corrupt our GL monad because we don't export unsafeIOToGL. > foo :: GL () > foo = unsafeIOToGL _foo As far as it goes, this technique is absolutely fine. We end up being able to write actions entirely in the GL monad: *Main> :t do { foo ; foo ; foo } do { foo ; foo ; foo } :: GL () ...as well as actions which mix general IO and GL calls : *Main> :t do { runGL foo ; putStrLn "Not a GL call" ; runGL foo } do { runGL foo ; putStrLn "Not a GL call" ; runGL foo } :: IO () The point of this message is actually to get rid of those annoying 'runGL' calls. When writing an IO action I want to be able to freely intermix IO and GL calls. When writing a GL-only action, I want to only use GL calls. And I want the type system to enforce that; and ideally, infer it too. So we define a type-class for "monad which can perform GL" : > class Monad m => MonadGL m where > runMonadGL :: m a -> IO a > embedGL :: GL a -> m a And we write an instance for IO: > instance MonadGL IO where > runMonadGL = id > embedGL = runGL Now we are able to bind our FFI call _foo slightly differently: > foo' :: MonadGL m => m () > foo' = embedGL foo This is interesting because, although we know that IO is in fact the only instance of MonadGL, there might in principle be others. (For example, GL is itself an instance of MonadGL if you put runMonadGL = runGL and embedGL = id). The type signature for foo' guarantees that it will run in *any* MonadGL, and therefore can't use any IO-specific effects, only the GL ones. Now we get the automatic type inference we want: *Main> :t do { foo' ; foo' ; foo' } do { foo' ; foo' ; foo' } :: (MonadGL t) => t () This only performs GL actions, no IO. *Main> :t do { foo' ; putStrLn "Normal" ; foo' } do { foo' ; putStrLn "Normal" ; foo' } :: IO () The single IO call here forces the type to IO, but we are not required to put noisy 'runGL's in front of every GL call. This technique is quite scalable in that you can have any number of MonadFoos representing different librarys with different kinds of state, and (as long as you don't mind the modest blow-up in type signature size) you get, for an arbitrary action, a type signature which pins down precisely what kinds of side-effect the action can have. It would, however, be a real pain to run through all the 'foreign' calls in the rather large GL library and add appropriate wrappers of the form 'embedGL . unsafeIOToGL'. Definitely a job for an automated tool. Incidentally, I don't believe this technique has any performance implication at all. The newtypes are all erased at compile time. Any comments? I'm sure this has been shown before but I don't remember where. Jules

3 2

Vital for real Haskell?
by Peter Verswyvelen 14 Sep '07

14 Sep '07

I showed Vital (http://www.cs.kent.ac.uk/projects/vital) to some teachers at my university and they where really enthousiastic. IMHO the Haskell community needs something like this, but for *real* Haskell (preferable with extensions), and not using Java... Is any work being done on something like this? Thanks, Peter

2 1

haskell and reflection
by Greg Meredith 13 Sep '07

13 Sep '07

Haskellians, Am i wrong in my assessment that the vast majority of reflective machinery is missing from Haskell? Specifically, - there is no runtime representation of type available for programmatic representation - there is no runtime representation of the type-inferencing or checking machinery - there is no runtime representation of the evaluation machinery - there is no runtime representation of the lexical or parsing machinery Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com

5 6

help getting happy
by Greg Meredith 13 Sep '07

13 Sep '07

Haskellians, The code pasted in below causes Happy to return parE when invoked with happy rparse.y -i . Is there anyway to get Happy to give me just a wee bit more info as to what might be causing the parE (which i interpret a 'parse error'). Best wishes, --greg { module Main where } %name rparse %tokentype { Token } %error { parseError } %token '{' { TokenLCurly } '}' { TokenRCurly } '[' { TokenLSquare } ']' { TokenRSquare } '(' { TokenLRound } ')' { TokenRRound } '@' { TokenAt } ',' { TokenComma } ';' { TokenSemi } lquote { TokenLQuote } rquote { TokenRQuote } %% Molecule : '{' '}' { Zero } | Name Reagent { Locate $1 $2 } | '@' Name { Decode $2 } ReagentList : Reagent { [ $1 ] } | ReagentList ';' Reagent { $1 ++ [$3] } Reagent : '?' '(' NameList ')' Mixture { Abstraction $3 $5 } | '[' Mixture ']' { Concretion $2 } Mixture : Molecule { Mix [ $1 ] } | '{' ReagentList '}' { Mix $2 } NameList : Name { [ $1 ] } | NameList ',' Name { $1 ++ [$3] } Name : lquote Mixture rquote { Name $2 } { parseError :: [Token] -> a parseError _ = error "Parse error" data Molecule = Zero | Locate Name Reagent | Decode Name deriving (Eq, Show) data Reagent = Abstraction [Name] Mix | Concretion Mix deriving (Eq, Show) data Mix = Mix [Molecule] deriving (Eq, Show) data Name = Name Mix deriving (Eq, Show) data Token = TokenLQuote | TokenRQuote | TokenLCurly | TokenRCurly | TokenLSquare | TokenRSquare | TokenLRound | TokenRRound | TokenComma | TokenSemi | TokenAt deriving Show lexer :: String -> [Token] lexer [] = [] lexer (c:cs) | isSpace c = lexer cs lexer ('{':cs) = TokenLCurly : lexer cs lexer ('}':cs) = TokenRCurly : lexer cs lexer ('[':cs) = TokenLSquare : lexer cs lexer (']':cs) = TokenRSquare : lexer cs lexer ('(':cs) = TokenLRound : lexer cs lexer (')':cs) = TokenRRound : lexer cs lexer (',':cs) = TokenComma : lexer cs lexer (';':cs) = TokenSemi : lexer cs lexer ('@':cs) = TokenAt : lexer cs lexer ('<':'<':cs) = TokenLQuote : lexer cs lexer ('>':'>':cs) = TokenRQuote : lexer cs main = getContents >>= print . rparse . lexer } -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com

3 3

Basic FFI with GHC
by Ronald Guida 13 Sep '07

13 Sep '07

How do I create C-libraries that I can load into GHCi? I am trying to do some basic FFI, and it's not working. Here's the background. I created three files, foo.h, foo.cpp, and test_foo.lhs. (source code below) Note: I am using MinGW/Msys under Windows XP. If I compile foo.cpp and then try to load test_foo into GHCi, I get an error. OTOH, if I compile test_foo with GHC, it works. I just don't understand why it works one way and not the other. What am I doing wrong? -- Ron ------------------------------ Shell commands ------------------------------ $ gcc -c foo.cpp $ ghci test_foo.lhs foo.o ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading object (static) foo.o ... done final link ... done [1 of 1] Compiling Main ( test_foo.lhs, interpreted ) During interactive linking, GHCi couldn't find the following symbol: foo This may be due to you not asking GHCi to load extra object files, [snip] $ ghc --make test_foo.lhs foo.o [1 of 1] Compiling Main ( test_foo.lhs, test_foo.o ) Linking test_foo.exe ... $ test_foo.exe Entering main y = 22 Exiting main $ ar rcs libfoo.a foo.o $ ghc --make test_foo.lhs -lfoo $ test_foo.exe Entering main y = 22 Exiting main $ ghci test_foo.lhs -lfoo ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading object (dynamic) foo ... failed. Dynamic linker error message was: addDLL: unknown error Whilst trying to load: (dynamic) foo Directories to search are: : user specified .o/.so/.DLL could not be loaded. ------------------------------ Source code ------------------------------ // foo.h extern "C" { __stdcall int foo(int x); } ------------------------------ // foo.cpp #include "foo.h" __stdcall int foo(int x) { return 3 * x + 1; } ------------------------------ test_foo.lhs > {-# OPTIONS_GHC -fglasgow-exts #-} > module Main > where > import Foreign > import Foreign.C > foreign import stdcall unsafe "foo" > c_Foo :: Word32 -> IO Word32 > main = do > putStrLn "Entering main" > let x = 7::Word32 > y <- c_Foo(x) > putStrLn $ "y = " ++ show y > putStrLn "Exiting main"

3 4

Haskell and State Monad.
by VinyleEm 12 Sep '07

12 Sep '07

Hello all, I am Vinay Emani, new to this forum. I am doing an academic project of writing an assembler cum linker in Haskell as part of building a compiler set written entirely in Haskell. Since i am new to the language, i thought it would do me good to look at some of the existing haskell code, be it in whatever project and written for whatever purpose. This should help me get started. In particular i need to find some project/program which extensively uses the State Monad. I tried looking at some of the existing open source projects at sourceforge. There are only limited number of projects there, some of them being incomplete. Could you please suggest me some project, from which i can learn the State Monad. Thanks very much Vinay Emani India -- View this message in context: http://www.nabble.com/Haskell-and-State-Monad.-tf4427176.html#a12629170 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

5 4

"Functional dependencies conflict between instance declarations"
by Peter Verswyvelen 12 Sep '07

12 Sep '07

The Haskell mailing list seems to be filled with people requesting information about this error, so I cannot resist to include myself in it ;-) I've read the information about funcdeps in the GHC user guide, and I think I understand how it works, but I get the error a lot, without having a clue why. Sometimes I get the error even when all the types of all the type parameters are completely different, so even when all parameters would be one-to-one dependent, I still don't get why I would get a conflict error. Does a wiki exists with possible reasons why this error occured and how to fix it? Thanks, Peter

4 5

Re: [Haskell-cafe] Re: Is "take" behaving correctly?
by PR Stanley 12 Sep '07

12 Sep '07

>Hi > > > The same should apply to head and tail. head or tail of [] should be []. > > > > What does the list think? > >Disagree, strongly. Its not even possible for head, since [a] -> a. >Wadler's theorems for free states that if head is given an empty list >the _only_ thing it can do is crash. What's the logic behind this? Thanks, Paul

3 2

Haddock/hscolour integration broken on Hackage?
by David Menendez 12 Sep '07

12 Sep '07

I was looking at the Data.Binary documentation[1] on Hackage, and I've noticed some problems with the associated source listings[2]. First, none of the "Source" links work. They all refer to fragment IDs (e.g., "#Binary") that are not defined. I'm not sure if this is a problem with hscolor, haddock, or hackage. Second, the source listing itself[2] is invalid HTML[3]. The W3C validator lists 678 errors. Of these, 677 are have to do with the line number anchors, all of which start with parentheses. This is bad not only because HTML requires fragment ids to start with a letter, but because parentheses are not allowed to occur in URIs. As a result, links to line numbers will come out looking like "Data-Binary.html#%28line100%29". [1] <http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary…> [2] <http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/src/Data-Bi…> [3] <http://validator.w3.org/check?uri=http%3A%2F%2Fhackage.haskell.org%2Fpackag…>

4 4

Re: Tiny documentation request
by manu 12 Sep '07

12 Sep '07

On Sep 11, 2007, Simon Marlow wrote: > > Please, please, someone do this for me. I tried, and failed, to > get the > layout right for the contents list in all browsers at the same > time. The > semantics of CSS is beyond my comprehension. > > Cheers, > Simon Hi Simon, On the page http://www.haskell.org/ghc/docs/latest/html/libraries/ index.html, you only need tables to display the foldable lists of modules (HTML tables were commonly used to display many "things" on a same line), but they can be replaced by nested lists with a bit of CSS : Check this page out : http://la.di.da.free.fr/haddock/ I can help further, if need be. Emmanuel

2 1