- Haskell-Cafe - Haskell.org

Re: Move MonadIO to base
by David Menendez 19 Apr '10

19 Apr '10

On Sun, Apr 18, 2010 at 5:02 PM, wren ng thornton <wren(a)community.haskell.org> wrote: > Heinrich Apfelmus wrote: >> >> Anders Kaseorg wrote: >>> >>> This concept can also be generalized to monad transformers: >>> >>> class MonadTrans t => MonadTransMorph t where >>> morph :: Monad m => (forall b. (t m a -> m b) -> m b) -> t m a >> >> [...] >> However, not all control operators can be lifted this way. Essentially, >> while you may "downgrade" an arbitrary selection of t m a values you >> may only promote one m a in return and all have to share the same >> return type a . In particular, it's not possible to implement >> >> lift :: (Monad m, MonadTrans t) => m a -> t m a > > Why not? > * morph says m(t m a) is a subset of (t m a) > * Monad m says we can fmap :: (a->b) -> (m a->m b) > * Monad (t m) says we can return :: a -> t m a > > lift ma = morph (\k -> k (fmap return ma)) Maybe something like this? lift m = morph (\k -> m >>= k . return) -- n.b., return and >>= are from different monads > Again, having m(t m a)->(t m a) is strictly more expressive than only having > (m a)->(t m a) because the former may avail itself of operations/operators > of t. join . lift :: m (t m a) -> t m a morph is more powerful than lift, but it isn't because of the type. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

1 0

vector recycling
by Ben 19 Apr '10

19 Apr '10

hello -- this is mostly a question for roman, or don, i guess. suppose i have a list of similarly-sized vectors, and i want to add them up (possibly with coefficients), to yield a result vector. something like module Main where import qualified Data.Vector.Generic as V import qualified Data.Vector.Unboxed as UV type Vec = UV.Vector Double axpy :: Double -> Vec -> Vec -> Vec axpy a x y = V.zipWith (+) (V.map (* a) x) y sumVecs :: [(Double, Vec)] -> Vec sumVecs axs = let (a, x) = head axs in foldl adder (V.map (* a) x) (tail axs) where adder :: Vec -> (Double, Vec) -> Vec adder v1 (a, x) = axpy a x v1 how to i write this in a way which ensures recycling / fusion, e.g. in-place updates? best regards, ben

3 4

ANN: vcd-0.1.0
by Tom Hawkins 19 Apr '10

19 Apr '10

The release adds a simple VCD parser (via Parsec) and minor changes to the VCD generation API. http://hackage.haskell.org/package/vcd

1 0

cabal: other-modules
by Johannes Waldmann 18 Apr '10

18 Apr '10

What is the purpose of the "Other-Modules" section in a cabal file? (I.e., can we drop it?) If it's just the set of dependencies of the "Exported-Modules", then a reasonable build system should be able to figure this out on its own. The current situation is that I have to manage this list manually (or is there some tool?) and if I forget to name some "other-module", then "cabal install" happily builds and installs (!) the package anyway, but I'm getting linker errors when using it. This is a nuisance, to say the least. J.W.

8 9

Re: Move MonadIO to base
by wren ng thornton 18 Apr '10

18 Apr '10

This bounced because I have different emails registered for cafe@ and libraries@, so forwarding it along to the cafe. wren ng thornton wrote: > wren ng thornton wrote: >> Heinrich Apfelmus wrote: >>> Anders Kaseorg wrote: >>>> This concept can also be generalized to monad transformers: >>>> >>>> class MonadTrans t => MonadTransMorph t where >>>> morph :: Monad m => (forall b. (t m a -> m b) -> m b) -> t m a >>> >>> [...] >>> However, not all control operators can be lifted this way. Essentially, >>> while you may "downgrade" an arbitrary selection of t m a values you >>> may only promote one m a in return and all have to share the same >>> return type a . In particular, it's not possible to implement >>> >>> lift :: (Monad m, MonadTrans t) => m a -> t m a >> >> Why not? >> * morph says m(t m a) is a subset of (t m a) >> * Monad m says we can fmap :: (a->b) -> (m a->m b) >> * Monad (t m) says we can return :: a -> t m a >> >> lift ma = morph (\k -> k (fmap return ma)) > > Or rather, > > lift ma = morph (\k -> join (fmap (k . return) ma)) > > That's what I get for typing without checking. The type of morph > requires us to Church-encode things needlessly; what we mean to say is: > morph (fmap return ma). > >> Again, having m(t m a)->(t m a) is strictly more expressive than only >> having (m a)->(t m a) because the former may avail itself of >> operations/operators of t. -- Live well, ~wren

1 0

problem with cabal on snow leopard
by Carter Schonwald 18 Apr '10

18 Apr '10

Hello all, I can't seem to find it documented anywhere as to the default directories that cabal puts its information in (its certainly not in ~/.cabal ), as I'm finding that even when I try to do a "reinstall" of the haskell platform, cabal thinks that all the libraries i removed are still there. how can i fix this? thanks -Carter

3 5

Confusions about the Haskell Platform (for Mac)
by Sean Leather 18 Apr '10

18 Apr '10

1. Why can't the platform download site be hosted on www.haskell.org instead of hackage.haskell.org? I see that there's a redirect, but (imho) it would be ideal to have www.haskell.org/platform be the standard URL in my browser. It is easier to remember (for typing) and more obvious (for appearances). 2. What is the difference between "Haskell" and the "Haskell Platform"? I see one or the other in various places. To get from www.haskell.org to downloading the Mac software, I go through "Download Haskell," "Get the Haskell Platform > Mac," and "Download Haskell for Mac OS X (intel)." 3. By looking at http://hackage.haskell.org/platform/mac.html , I have no idea what I'm going to get when I click the "Download Haskell for Mac OS X (intel)" link. It would be nice to know what I'm getting myself into before I commit to waiting for this 137.9 MB file. Thanks to the wonder of deep links, one can also not be expected to traverse the path that I did in #2. Similarly, if I come to this link directly, I have no easy way of navigating to try to figure out what "Haskell" or "GHC" is. 4. The current link for the Mac image points to http://hackage.haskell.org/platform/2010.1.0.0/haskell-platform-2010.1.0.1-…. Note the inconsistency between the version in the directory and file names. 5. The directions on http://hackage.haskell.org/platform/mac.html say: After downloading: * Open the .dmg file * Follow the install instructions I see no "install instructions" in the .dmg file. I only see the following files: * GHC-6.12.1-i386.pkg * Haskell Platform 2010.1.0.1.pkg * Uninstall GHC 6. Since there are no "install instructions," I am not sure which .pkg to install first. Of course, fix #3 and you hopefully fix this one. 7. Why can't I have a single .pkg file? Why do I have an "Uninstall GHC" and not an "Uninstall Haskell Platform"? -- I don't expect all of the above to necessarily have a direct solution. They are just my observations to share. Some of them are from the point of view of a newcomer, and some are from a perfectionist. Regards, Sean

10 26

Re: [Haskell-cafe] Embedded funcional programming?
by Patai Gergely 18 Apr '10

18 Apr '10

Hello, > I'm new to this, so the only problems I see are finding a compiler > that targets the platform (ARM7, for instance, or others) and > uploading the compiled firmware to the device. I used Hume [1] to program Mindstorms NXT robots (ARM7) as well as Tmote Sky sensors (MSP430). In both cases I ported the HAM virtual machine and interpreted bytecode. In the case of NXT I used the hardware layer of leJOS [2], simply ripping out the JVM and replacing it with HAM. As for the Tmote Sky, the VM sat on top of Contiki [3], so it was possible to send HAM bytecode over the air, and the sensor would intercept it, stop the currently running program and execute the new one. Hume can also be compiled directly to C, and I got it to run on a home-brew LPC2106 based embedded platform (also with an ARM7 core) we use in education. The main problem was the size of the generated code. See [4] for details. My overall impression is that Hume could be a very nice language to program embedded systems with, given proper tool support (for starters, it's really crying for a visual editor) and a high-quality compiler. Gergely [1] http://www-fp.cs.st-andrews.ac.uk/hume/index.shtml [2] http://lejos.sourceforge.net/ [3] http://www.sics.se/contiki/ [4] http://www-fp.cs.st-andrews.ac.uk/hume/papers/pg_thesis/ -- http://www.fastmail.fm - Email service worth paying for. Try it for free

1 0

GHC, odd concurrency space leak
by Jesper Louis Andersen 18 Apr '10

18 Apr '10

A problem with GHC? =================== This post describes some odd behaviour I have seen in GHC 6.12.1 when writing Combinatorrent. The post is literate Haskell so you can run it. The executive summary: A space leak occurs when a new process is spawned from inside another process - and I can't figure out why. I am asking for help on haskell-cafe. We begin by upgrading GHC from Haskell98 to something mature and modern: > {-# LANGUAGE GeneralizedNewtypeDeriving #-} And then we do the import-tango: > module Main where > > import Control.Monad.Reader > import Control.Monad.State > > In our system, a *Process* is an identifier for a thread of execution. Since these heavily makes use of the following imports, > import Control.Concurrent > import Control.Concurrent.STM it is beneficial to make processes live in the IO-monad. However, it turns out that having everything living in the IO monad is a clunky idea. A Process also has a current configuration: The channels and variables on which it can communicate for instance. The configuration is not expected to be changed over the course of the process running. For data which do change when the process runs, we want some state tracking. Luckily, the Xmonad X-monad comes to our rescue. In all its gory and glory details, we generalize it and rewrite it for our processes, which is how they are used in combinatorrent. Our model-kit for building new threads of execution is the following beast: > newtype Process a b c = Process (ReaderT a (StateT b IO) c) > deriving (Functor, Monad, MonadIO, MonadState b, MonadReader a) Note that the automatic derivations of *MonadState b* and *MonadReader a* makes GHC spit our some mkUsageInfo warnings in its generation of the .hi-files. They don't seem to be dangerous. Glueing instructions for our model kit is given by spawning off new threads: > run :: a -> b -> Process a b c -> IO (c, b) > run c st (Process p) = runStateT (runReaderT p c) st > > spawn :: a -> b -> Process a b () -> IO ThreadId > spawn c st p = forkIO $ run c st p >> return () Our first dummy --------------- Machinery for having fun is now in place. Here is a crash-test-dummy we would like to play with: > main1 = do > spawn () () (forever $ return ()) > threadDelay (3 * 1000000) > > -- main = main1 Note that the given units () and () are usually much more complicated, but for the sake of this minimal example units will do. And running that does what we expect it to do: ./Post +RTS -tstderr <<ghc: 1156600984 bytes, 2207 GCs, 2668/2668 avg/max bytes residency (1 samples), 1M in use, 0.00 INIT (0.00 elapsed), 2.72 MUT (2.67 elapsed), 0.28 GC (0.34 elapsed) :ghc>> At this point, we got our own little processor-heater installed in our room. But spring is coming to the Northern hemisphere, so we have little use for this until November or December. To actually make our system do something, we build this gem: > p1 :: Process () () () > p1 = forever $ return () > > startp1 :: IO ThreadId > startp1 = spawn () () p1 > > startp2 :: IO ThreadId > startp2 = spawn () () (forever $ > do liftIO startp1 > liftIO $ putStrLn "Delaying" > liftIO $ threadDelay (10 * 1000000)) > > main2 = do > putStrLn "Main thread starting" > startp2 > threadDelay (1 * 1000000) > > main = main2 Running *this* beast gives: ./Post +RTS -tstderr Main thread starting Delaying <<ghc: 2532328160 bytes, 4831 GCs, 63629171/319163472 avg/max bytes residency (10 samples), 629M in use, 0.00 INIT (0.00 elapsed), 1.02 MUT (1.09 elapsed), 1.57 GC (1.91 elapsed) :ghc>> Notice the improvement! Now we both get to burn the CPU and we have a space leak! Removing the "forever" in startp2 will make this code not leak space. startp2 only spawns a single process, which then runs and each time it takes a cycle in the forever-loop, it builds up live heap. This boggles my mind. Why does this code leak like mad? What could one do to remedy the leak? The leak is PAP and GHC.Base.sat_... (according to -hd heap profiling). In my combinatorrent code it is a ->StateT (does anyone know what PAP and ->StateT means and where to find more definitions like these?). In confusion, -- J.

9 24

building Haskell Platform for CentOS 5.2 with a /tmp mounted noexec
by Chris Dornan 18 Apr '10

18 Apr '10

Hi Everyone, Just to report that I now have Haskell Platform built for CentOS 5.2 with a /tmp mounted noexec. Looking back, the first main hurdle was getting GHC built for CentOS 5.2 (which uses Linux 2.6.9/glibc 2.5), but the procedure was pretty straight forward: . Keep trying generic binary Linux ghc packages until one that works is found (in this case ghc-6.8.3); . With ghc-6.8.3 installed, download the src tar ball for the next ghc release (6.10.1) and build and install that; . With the newly built GHC on the PATH, rinse and repeat until ghc-6.12.1 installed. It took a fair bit of time but, as far as I can tell, every single build worked flawlessly. My next task was getting cabal-install to work, which nearly defeated me, but it turns out that because CentOS mounts /tmp noexec, so all I had to do was get cabal-install to use somewhere else. As I was pithily advised: alias cabal="TMPDIR=/foo cabal" With that in place, AFAIK, the Haskell Platform built from source with the various configure scripts giving me enough hints to 'yum install' all the required CentOS packages. Thanks to everyone for their help. Chris

3 3