February 2008 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

ghci and ghc -threaded broken with pipes & forking
by John Goerzen 29 Dec '08

29 Dec '08

Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John

13 44

Arrow without `>>>'
by Valery V. Vorotyntsev 03 Sep '08

03 Sep '08

Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv

3 3

gmp
by Christian Maeder 17 Apr '08

17 Apr '08

I understand that gmp is needed for the certain libraries like the Prelude with Double and Integer. But I do not understand why gmp is so deeply buried in the rts. Are the basic types Int and Pointer not enough to write a compiler like ghc? Cheers Christian

7 10

static constants -- ideas?
by Jason Dusek 03 Mar '08

03 Mar '08

I have an awkward programming problem -- I need to take a dictionary, parse it, build a bunch of intermediate lists and then make maps and tries out of the list. A "programming problem" because it's taken me a fair amount of effort to pull together the parser and list generator -- and "awkward" because a 69000 item list, [(String, [(String, String)])], does not compile under GHC (stack overflow). (It's not likely to compile under anything else, either!) Members of #haskell have urged me to load the offending material from a file; indeed, it only takes ten seconds to parse the dictionary and build the lists, sort them and dump them back out again -- but it offends my sensibilities. I don't want to wait ten seconds to load my dictionary every time. I could use the FFI, then I can make the trie and lists all in C. That'd work great. My list likely uses too much RAM now, anyways. I'm considering one other option though -- I wonder if I can build large constants in GHC Core? If anybody has tried it -- or found some other way to make big huge constants in Haskell -- I would sure like to know about it. On another note, I am extremely curious about the difference between statically compiling a list and building it at runtime. I find it hard to wrap my head around the fact that I can build the list at runtime in a short time, but can not compile it without eating all of my machine's RAM. Is it due to laziness, maybe? Well, no -- because I subject the whole list to a sort. It's not just streaming records in from one IO handle and out another. -- _jsn

6 20

STM and fairness
by Josef Svenningsson 29 Feb '08

29 Feb '08

Hi, I'd like to know a bit about the STM implementation in GHC, specifically about how it tries to achieve fairness. I've been reading "Composable Memory Transactions" but it does not contain that much details on this specific matter. What I want to know boils down to this: what order are processes run which have been woken up from a call to retry? When programming with condition variables the standard behaviour is that the process which has waited the longest is the first one to get to run. But that doesn't seem to be the behaviour here. Consider the following program: \begin{code} module STMFair where import Control.Concurrent import Control.Concurrent.STM test n = do v <- newTVarIO 0 mapM_ (\n -> forkIO (process n v) >> threadDelay delay) [1..n] atomically (writeTVar v 1) threadDelay delay delay = 500000 process id var = do putStrLn ("Process " ++ show id ++ " started") atomically $ do v <- readTVar var if v == 0 then retry else return () putStrLn ("Process " ++ show id ++ " finished") \end{code} When I run 'test 2' I expect it to print: Process 1 started Process 2 started Process 1 finished Process 2 finished This would correspond to the oldest process being executed first. But that is not what happens instead I get this (ghci 6.8.2, Ubuntu Linux): Process 1 started Process 2 started Process 2 finished Process 1 finished This is certainly not the behaviour I would want. I discovered this behaviour when implementing the dining philosophers using STM and there one of the philosophers gets starved. Except, that he's not quite starved. When I run the simulation long enough he will eventually be able to eat but then for a long time there will be some other philosopher that is starved. I find this behaviour very mysterious and it would be nice to have some light shed on it. Apart from this mysterious behaviour it seems quite easy to improve the fairness of the implementation. From my examples above it seems that the wait queues for a transactional variable do contain the processes in the order they call retry (try running 'test n' for some large n). It just seems that they are given to the scheduler in the wrong order, so all that needs to be done is to reverse the list. Am I right? Thanks for reading, Josef

3 3

Re: H98 Text IO
by Ben Franksen 28 Feb '08

28 Feb '08

David Leuschner wrote: > If I write simple program just printing a non-ASCII string to the terminal > or to a file I'd expect that I can read it on the screen or using my > favorite text editor without having change anything -- neither in my > terminal nor in my program. When I run the program on my platform don't > mind if somebody else might get differently encoded output from the same > program as long as I get what I expect. I think this is sensible advice. Furthermore I want to be able to chose an encoding (e.g. by setting my environment), even for file/socket IO, instead of being locked into utf-8. Thus, for Linux, I'd say always use the environment encoding. More advanced stuff like sending in a certain encoding e.g. over network or to a foreign file system should not use H98 IO but newer libraries that allow to set the encoding programmatically, or encode yourself and read/write Word8. Cheers Ben

1 0

Exports of STM constructors.
by Sterling Clover 27 Feb '08

27 Feb '08

I was recently bitten by the urge to hack around with STM, and discovered to my dismay that there's no way to get at the primitive constructors for TVar and STM, both of which are defined in GHC.Conc. Given that, when we so desire, we can get at the primitives to break IO into pieces, manually unbox integers and such, and that the primitives for working with MVars are similarly exposed through appropriate imports, it would be really nice (or, well, at least fun) to be able to do the same for STM. --S

1 0

Re: H98 Text IO
by Matthew Bentham 27 Feb '08

27 Feb '08

----- Original Message ---- > From: Johan Tibell <johan.tibell(a)gmail.com> > To: Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> > Cc: Haskell Libraries <libraries(a)haskell.org>; GHC-users list <Glasgow-haskell-users(a)haskell.org>; Simon Marlow <simonmarhaskell(a)gmail.com> > Sent: Wednesday, February 27, 2008 9:25:39 AM > Subject: Re: H98 Text IO > > On Wed, Feb 27, 2008 at 1:06 AM, Duncan Coutts > wrote: > > As a data point, Java and python use "always locale" as default if you > > don't specify an encoding when opening a text stream. > > > > I think personally I'm coming round to the "always locale" point of > > view. We already have no cross-platform consistency for text files > > because of the lf vs cr/lf issue and we have no cross-implementation > > consistency. > > I think following Java and Python in this matter is a good idea and > leads to fewer surprises for developers. If you want files created on > one machine to work on another you have to be explicit about encoding. I'm a newcomer to haskell so I don't want to goof by offering any naive opinions, but I would like to inform the discussion by linking to a couple of useful things. This blog post on encodings in python (mostly related to the behaviour of the standard input/output streams): http://drj11.wordpress.com/2007/05/14/python-how-is-sysstdoutencoding-chose… Particularly: "It’s not unreasonable to have a program that wants to encode its outputin a particular encoding. The example I gave earlier still seemsreasonable to be, a program that takes input in one encoding andrecodes to a different encoding on its output, with both the input andoutput encoding specified on the command line. Clearly such a programshould be able to use stdin and stdout so that it can form part of apipe. So how in Python do I change sys.stdout to use a particular encoding? It’s a right pain." And the reference to the POSIX documentation related to locale, mentioned earlier in this thread: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html The problem that I see is generally that because stdin/out/err are _already_open_ by the time they reach the haskell program, it is pretty hard for the developer "to be explicit about encoding" if no library is provided to effectively change the encoding used by an already-open stream.

2 1

Re: H98 Text IO
by Chris Kuklewicz 27 Feb '08

27 Feb '08

Small correction: I think "./prog in vs ./prog < in " and "utf8" should be "ok". (and I thought this was switched to Glasgow-haskell-users(a)haskell.org) David Leuschner wrote: >> Let me try and summarise: > > Thanks for the great summary! And thanks to Emacs' table mode here're the > results displayed as a table: > > +--------------------------------+-----+--------+------+-------+-------+ > | | now | locale | utf8 | mix-A | mix-B | > +--------------------------------+-----+--------+------+-------+-------+ > | putStrLn "..." | - | ok | - | ok | ok | > +--------------------------------+-----+--------+------+-------+-------+ > | ./prog vs ./prog | cat | ok | ok | ok | - | ok | > +--------------------------------+-----+--------+------+-------+-------+ > | ./prog in vs ./prog < in | - | ok | - | ok | - | > +--------------------------------+-----+--------+------+-------+-------+ > | ./prog vs ./prog | hexdump -C | ok | ok | ok | - | ok | > +--------------------------------+-----+--------+------+-------+-------+ > > > The mixtures are good ideas but can give inconsistent and suriprising > results (especially when debugging encoding issues). And if our CEO would > have known that ... putStrLn <his-name> ... doesn't work he'd have > probably ruled out Haskell right from the start. Even "utf8" gives > surprising results: I'd be very surprised if my Mac-written Haskell > program outputs junk on Windows or Linux even if the byte sequence is > exactly the same UTF-8 text. > > Personally I think consistency on a single platform is more important than > trying to achieve cross-platform consistency which involves a lot more > than just encoding. If you've reached that point with your program you're > probably anyway using "advanced functions" to exactly specify what will be > output. Following "the principle of least surprise" is also a good idea. > > Cheers, > > David > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

2 1