- Haskell-Cafe - Haskell.org

OS Abstraction module??
by Galchin Vasili 23 Oct '07

23 Oct '07

Hello, In the Haskell libraries, is there an OS abstraction module, that would "hide" the POSIX API and Win-32 API? If not, this would be nice so that Haskell "programs" could be written in an OS independent manner! Kind regards, Bill Halchin

9 20

Using Haddock to document ADTs
by Alfonso Acosta 23 Oct '07

23 Oct '07

Hi all, I'm beginning to get familiar with Haddock and I want to document a library which, as usually happens, has some ADT definitions. I'd like to document the ADTs both for the end-user (who shouldn't be told about its internal implementation) and future developers. Let's imagine my library is called FooLib, defines an ADT whose implementation is hidden by an outer module. =========== FooLib/ADT1.hs ===== -- | This module defines my type ADT1 module ADT1 -- | This type implements whatever and. As you can see it's implemented -- using blah blah so that is more efficient because of blah blah data ADT1 a = ... ========== Foolib.hs ============ -- | This is Foolib which is aimed at whatever module Foolib (ADT) where import ADT =================== Generating documentation for Foolib.hs with this Haddock annotations will unfortunatelly reveal implementation details since the annotation of ADT1 is forwarded. My question is, How can I generate documentation for both developers and the end-users using the same Haddock annotations? I'm beginning to think it would be a good idea to distinguish those two cases (documentation for end-users and internal developers) in Haddock, but I'm probably wrong since it seems a common thing and wasn't implemented yet. Best Regards, Alfonso

3 4

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