October 2007 - Haskell-Cafe

Back on opengl win32 again? no window
by bbrown 23 Oct '07

23 Oct '07

Ok, sorry to bring this back up again. I asked before and kind of went to a working linux system. My question; On Win32, has anyone seen where you try to run the application but the window will not stay open. There are no errors, the window with 3D objects will not stay open. I was using a recent haskell 6.6.1 (ghc-6.6.1- i386-windows.exe). I asked before it seemed like the others suggested I use freeglut and use that. But I dont really need freeglut extensions. I am using basic opengl. I noticed that opengl is included in the ghc (mingw) I downloaded. Also, the code compiles, just doesnt run. The machine itself is a 3.2ghz, nvidia machine (win2k). I know opengl code should work. You can see the source here: http://octanemech.googlecode.com/svn/trunk/octanemech/src/misc/camera/ I compiled with: ghc --make MechCamera.hs -prof -auto-all -o $@ Basically the initialization aspect: import Graphics.Rendering.OpenGL import Graphics.UI.GLUT import Data.IORef mechLaunchGLWindow = do getArgsAndInitialize -- Initialize with the following settings -- Double buffer, RGBA color -- Alpha components supported, Depth buffer initialDisplayMode $= [ DoubleBuffered, RGBAMode, WithDepthBuffer, WithAlphaComponent ] initialWindowSize $= Size mechScreenWidth mechScreenHeight createWindow mechWindowTitle mechInitGL let mainCamera = initCamera (1.4, 4.2, -4.5) (0,0,0) (0,0,0) mainMech = initMech (0, 0, 0) (0, 0, 0) mainCameraRef <- newIORef(mainCamera) mainMechRef <- newIORef(mainMech) -- Set the OpenGL callbacks displayCallback $= displayGameLoop mainCameraRef mainMechRef -- Set the keyboard callback for handling actions keyboardMouseCallback $= Just (mechKeyPressed mainCameraRef) idleCallback $= Just idle mainLoop -- Berlin Brown [berlin dot brown at gmail dot com] http://botspiritcompany.com/botlist/?

1 1

ANNOUNCE: zlib and bzlib 0.4 releases
by Duncan Coutts 23 Oct '07

23 Oct '07

I'm pleased to announce updates to the zlib and bzlib packages. The releases are on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bzlib What's new in these releases is that the packages work with a wider range of systems and versions of dependent packages. In particular: * Works "out of the box" on Windows It uses a bundled copy of the zlib C library (version 1.2.3) on Windows and uses the system zlib on all other platforms. * Works with ghc-6.4, 6.6, 6.8 * Works with new bytestring versions * Works with older versions of zlib (eg zlib 1.1 on MacOS X) They require Cabal-1.2.1 (which is also available on hackage and works with all ghc versions). The zlib and bzlib packages provide functions for compression and decompression in the gzip and bzip2 formats. Both provide pure functions on streams of data represented by lazy ByteStrings: compress, decompress :: ByteString -> ByteString This makes it easy to use either in memory or with disk or network IO. For example a simple gzip compression program is just: > import qualified Data.ByteString.Lazy as ByteString > import qualified Codec.Compression.GZip as GZip > > main = ByteString.interact GZip.compress Or you could lazily read in and decompress .gz file using: > content <- fmap GZip.decompress (ByteString.readFile file) Both packages are bindings to the corresponding C libs, so they depend on those C libraries. Fortunately both zlib and bzlib2 are available on every OS. It also means that the compression speed is as you would expect since it's the C lib that is doing all the work. The zlib package is now being used in cabal-install to work with .tar.gz files. So it has actually been tested on Windows. The development versions have new homes on code.haskell.org. I'm very happy to get feedback on the API, the documentation or of course any bug reports. Duncan

2 2

Re: [Haskell] [Fwd: undecidable & overlapping instances: a bug?]
by Mark P Jones 23 Oct '07

23 Oct '07

[Sorry, I guess this should have been in the cafe ...] Simon Peyton-Jones wrote: > The trouble is that > a) the coverage condition ensures that everything is well behaved > b) but it's too restrictive for some uses of FDs, notably the MTL library > c) there are many possibilities for more generous conditions, but > the useful ones all seem complicated > > Concerning the last point I've dumped the current brand leader > for (c) into http://hackage.haskell.org/trac/ghc/ticket/1241#comment:15. > > Better ideas for (c) would be welcome. Let's take the declaration: "instance P => C t where ..." The version of the "coverage condition" in my paper [1] requires that TV(t_Y) \subseteq TV(t_X), for each dependency (X->Y) \in F_C. (I'm using the notation from the paper; let me know if you need more help to parse it.) This formulation is simple and sound, but it doesn't use any dependency information that could be extracted from P. To remedy this, calculate L = F_P, the set of functional dependencies induced by P, and then expand the right hand side of the set inequality above by taking the closure of TV(t_X) with respect to L. In symbols, we have to check that: TV(t_Y) \subseteq TV(t_X)^+_L, for each (X->Y) \in F_C. I believe (but haven't formally proved) that this is sound; I don't know how to make a more general "coverage condition" without losing that. I don't know if it's sufficient for examples like MTL (because I'm not sure where to look for details of what that requires), but if it isn't then I'd be very suspicious ... All the best, Mark [1] http://www.cs.pdx.edu/~mpj/pubs/fundeps-esop2000.pdf

5 10

Learning hierarchy
by Lutz Donnerhacke 23 Oct '07

23 Oct '07

Hi, in order to upload my teaching programms to hackage, I look for an accepted hierarchy to put the modules into. My current version is Learning.Donnerhacke.Algorithms.Sort ... etc. pp. Would such a hierarchy make sense? Is the a hope for inclusion of other modules? The main purpose of this moduls in my special case are: Implementation of the algorithms from Sedgewick's famous book. They are combined with a ver short program

1 1

Beginners problem with the type system
by Henrik Tramberend 23 Oct '07

23 Oct '07

Dear Hasekellers, I am trying to build some abstractions on top of the module Control.Concurrent and run into a problem with the type system that I do not understand. In particular, I want to define two classes 'Channel' and 'Port' (see below) that define a common interface for several concrete implementations with different synchronization characteristics. The following code is a simplified excerpt that demonstrates the problem: > module Main where > import Control.Concurrent.MVar > class Channel c where > port :: Port p => c a -> IO (p a) > class Port p where > take :: p a -> IO a > put :: p a -> a -> IO () The problem arises when I instantiate the 'Channel' class and implement the 'port' function. > data C a = C (P a) > instance Channel C where > port (C p) = return p Couldn't match expected type `p' (a rigid variable) against inferred type `P' `p' is bound by the type signature for `port' Expected type: p a Inferred type: P a In the first argument of `return', namely `p' In the expression: return p I am quite new to Haskell and my knowledge of how the type system works is fairly limited. Any help on this particular problem will be greatly appreciated, but any pointers to reading material that brings me closer to enlightenment are also very welcome. Thanks, Henrik > newC = do > p <- newP > return (C p) > data P a = P (MVar a) > newP = do > v <- newEmptyMVar > return (P v) > instance Port P where > take (P mv) = takeMVar mv > main = do > c <- newC > p <- port c > put p 1

3 3

Polymorphic (typeclass) values in a list?
by TJ 23 Oct '07

23 Oct '07

Why is it illegal to store values of differing types, but which instance the same class, into a list? e.g. a = [ 1, 2.0 ] :: Num a => [a] After all, sometimes all you need to know about a list is that all the elements support a common set of operations. If I'm implementing a 3d renderer for example, I'd like to have class Renderable a where render :: a -> RasterImage scene :: Renderable a => [a] Instead of hardcoding a bunch of types as being Renderable, as in data Renderable = Point Something | Line Something | Polygon Something scene :: [Renderable] Or maybe data Point = Point Something data Line = Line Something data Polygon = Polygon Something scene :: { points :: [Point], lines :: [Line], polygons :: [Polygons] } Is there a way of achieving what I want to do? Existentials maybe? I'm still learning the basic stuff and don't grok existentials at all, but I even if I use those, I'll still have to wrap things up in a constructor, won't I? Thanks a bunch, TJ

9 16

Function Types
by PR Stanley 23 Oct '07

23 Oct '07

Hi What are the rules for calculating function types? Is there a set procedure ? Thanks, Paul

3 2

Transformation sequence
by Andrew Coppin 23 Oct '07

23 Oct '07

I'm writing some code where I take an expression tree and transform it into another equivilent one. Now it's moderately easy to write the code that does the transformation. But what I *really* want is to print out the transformation *sequence*. This appears to be much more awkward. What I have is a function like this: transform :: Expression -> [Expression] The trouble is, if you want to apply the transformation recursively, things get very messy. Oh, it *works* and everything. It's just really messy and verbose. In Haskell, this is usually a sign that you want to start applying some ingenious trickery... but I'm having an ingeniety failure here. Suppose, for example, that in one case you want to recursively transform two subexpressions. I end up writing something like transform (...sub1...sub2...) = let sub1s = transform sub1 sub2s = transform sub2 in map (\sub1' -> put sub1' back into main expression) sub1s ++ map (\sub2' -> put sub2' back into main expression) sub2s After you've typed that a few times, it becomes *very* boring! But I can't think of a clean way to abstract it. :-( It's *almost* like you want to use the list monad: transform (...sub1...sub2...) = do sub1' <- transform sub1 sub2' <- transform sub2 return (put sub1' and sub2' back into the main expression) Except that that doesn't quite work properly. As shown above, I actually want to go through all the transformation steps for the first branch, and *then* all the steps for the second branch. Any hints?

8 12

wordsBy in the base libraries?
by Maxime Henrion 23 Oct '07

23 Oct '07

Hello all, What do you think about having a wordsBy function in the standard libraries? It often comes in handy. > wordsBy :: (a -> Bool) -> [a] -> [[a]] > wordsBy p s = case dropWhile p s of > [] -> [] > ':rest -> (s':w) : wordsBy p s'' > where (w, s'') = break p rest This version takes care of avoiding a redundant character check that is present in the standard definition of the words function, originally discovered by Neil Mitchell, see his blog post here: http://neilmitchell.blogspot.com/2007/07/equational-reasoning-in-haskell.ht… Then we can define the words function naturally: > words :: String -> [String] > words = wordsBy isSpace Cheers, Maxime

5 11

Re: [Haskell-cafe] Function Types
by PR Stanley 22 Oct '07

22 Oct '07

f x = x x :: a f x :: b therefore f :: a -> b x = a and x = b therefore a = b therefore f :: a -> a Simple mappings are easy to work out. It's the more detailed stuff I'm not sure about. f g x y = g x (y x) Cheers, Paul At 03:15 23/10/2007, you wrote: >On 10/22/07, PR Stanley ><<mailto:prstanley@ntlworld.com>prstanley(a)ntlworld.com> wrote: >Hi >What are the rules for calculating function types? >Is there a set procedure ? >Thanks, Paul > > >There must be a set procedure, since otherwise the compiler could >not function! =) > >Seriously, though, I'm not exactly sure what you're asking >for. Could you maybe provide a few examples of the kind of thing >you're asking about? > >-Brent

4 3