- Libraries - Haskell.org

The Proper Definition of (evaluate :: a -> IO a)
by Isaac Dupree 10 May '07

10 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The obvious "evaluate x = x `seq` return x" fails one of the following laws for evaluate: " evaluate x `seq` y ==> y evaluate x `catch` f ==> (return $! x) `catch` f evaluate x >>= f ==> (return $! x) >>= f Note: the first equation implies that (evaluate x) is not the same as (return $! x). " However, strictness does not obey the monad laws. A correct definition for IO would be "evaluate x = (x `seq` return x) >>= return", or equally, "(return $! x) >>= return", or even more horrible-looking, "fmap id (return $! x)"! This works because (at least in present Haskell implementations) IO's (>>=) is not strict in its first argument. Noticing that this function has been implemented (slightly wrongly) for NHC in base, so I mention this odd suggestion. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGPHKtHgcxvIWYTTURAmT2AKC+pipeHff1jVOCqxjOOz2p+6/JqQCeNqAN bjkaLwbn+BRVCya2e49diF4= =J9iV -----END PGP SIGNATURE-----

6 9

Re: Fwd: Report this to bug-autoconf@gnu.org
by Simon Marlow 10 May '07

10 May '07

Forwarding to list on behalf of "Marek Burza" <mkburza(a)gmail.com>. > ---------- Forwarded message ---------- > From: "Marek Burza" <mkburza(a)gmail.com <mailto:mkburza@gmail.com>> > To: libraries(a)haskell.org <mailto:libraries@haskell.org> > Date: Thu, 10 May 2007 09:50:23 +0200 > Subject: Fwd: Report this to bug-autoconf(a)gnu.org > <mailto:bug-autoconf@gnu.org> > Hi, > > When I tried to install network package an error ocurred to me > below you can find a more detailed description on what it is and how it > can be fixed > - I figured you might be interested > > Best regards, > Mark > > ---------- Forwarded message ---------- > From: *Ralf Wildenhues* < Ralf.Wildenhues(a)gmx.de > <mailto:Ralf.Wildenhues@gmx.de>> > Date: 10-May-2007 08:59 > Subject: Re: Report this to bug-autoconf(a)gnu.org > <mailto:bug-autoconf@gnu.org> > To: Marek Burza < mkburza(a)gmail.com <mailto:mkburza@gmail.com>> > Cc: bug-autoconf(a)gnu.org <mailto:bug-autoconf@gnu.org> > > Hello Marek, > > Thanks for the report. > > * Marek Burza wrote on Wed, May 09, 2007 at 05:57:45PM CEST: > > > > I was trying to install an extension (network-2.0) to Haskell on cygwin > > and I got an error or warning which requested to be reported to you :) > > You can see the output below and if you need more info I'll be glad to > > provide it to you. > [...] > > > checking winsock.h usability... no > > checking winsock.h presence... yes > > configure: WARNING: winsock.h: present but cannot be compiled > > configure: WARNING: winsock.h: check for missing prerequisite headers? > > configure: WARNING: winsock.h: proceeding with the preprocessor's result > > configure: WARNING: ## ------------------------------------ ## > > configure: WARNING: ## Report this to bug-autoconf(a)gnu.org > <mailto:bug-autoconf@gnu.org>. ## > > configure: WARNING: ## ------------------------------------ ## > > checking for winsock.h... yes > [...] > > Please read > > http://www.gnu.org/software/autoconf/manual/html_node/Present-But-Cannot-Be… > > and then show that to the maintainer of the Haskell package, who can > fix this in his package. The error becomes clearer if you look at the > part of the config.log file that deals with this compile failure (and > maybe also some Cygwin documentation). > > > nlv13536@NLVEHVRES2DT1C9 $ runghc Setup.hs build > > Preprocessing library network-2.0.. . > > Building network-2.0... > > cbits\ancilData.c: In function `sendFd': > > > > cbits\ancilData.c:47:0: > > error: variable `msg' has initializer but incomplete type > [...] > > FWIW, these may or may not be followup errors; I don't know. > > Cheers, > Ralf >

1 0

problems using ghc-6.6.1 (due to fgl-5.4.1)
by Christian Maeder 09 May '07

09 May '07

I wrote: > Dear Hets- and GHC-Developers, > we have a problem using ghc-6.6.1. The created hets binary runs a > couple > of times slower than the one created using ghc-6.6. This problem is gone when I install and use fgl-5.3 (where "hiding (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). I strongly suspect the new functions context1l' and context4l' in Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic slow down. In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic edge (an edge from and to the very same node) was only returned as ingoing edge and not as outgoing one. (a design decision documented elsewhere). I think, the change in fgl-5.4.1 now returns a cyclic edge also as outgoing edge (and possibly twice as ingoing one). Our application heavily uses in- and outgoing edges that may be cyclic. Christian P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1

2 2

darcs patch: Make Gen an instance of Applicative
by Duncan Coutts 09 May '07

09 May '07

Thanks to Björn Bringert and Koen Claessen, the QuickCheck 2 darcs repository is now hosted at: darcs get http://darcs.haskell.org/QuickCheck/ 'darcs send' will send patches to the libraries mailing list. We figured this list is appropriate since QC is a tool that many people depend on so getting a wider range of reviewers is good and yet development activity isn't likely to be so high that a seperate mailing list would be needed. Here's one such patch: Tue May 8 17:32:04 BST 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Make Gen an instance of Applicative So we can use the nice syntax: f <$> a <*> b <*> c

2 2

Re: [Haskell] -compiler-options vs {#-LANGUAGE Flags-#}
by John Meacham 09 May '07

09 May '07

On Thu, Apr 05, 2007 at 07:07:34PM +0100, David House wrote: > On 05/04/07, John Meacham <john(a)repetae.net> wrote: > >A very big problem with the pragma as it relates to > >Distribution.Extension is that it is unextensable. > > Yet another use case for Andres Löh and Ralf Hinze's open datatypes > [1]. Shame they're still lacking an implementation. > > [1]: http://www.informatik.uni-bonn.de/~loeh/OpenDatatypes.html Well, The mistake is making them a data type at all, cabal doesn't do anything with them other than pass them to the appropriate compiler (perhaps after translating them to flags if the compiler doesn't support the LANGUAGE pragma). it should not have to enumerate a set of valid ones inside its code, just translation tables for the various compilers (or a note saying the compiler supports the LANGUAGE pragma, so the table isn't needed) likewise for the License field and getting rid of all built in preprocessors. cabal is just too inflexible (and much bigger than it needs to be) with so much stuff built in. ideally, the compilers would also not be hard coded into it, but that would be a bigger task but fixing up the rest shouldn't be hard. as a compiler writer, what I would love is if there were a document on the cabal site that said "to allow cabal to use your compiler, have it (or a wrapper) accept the following command line options and do X with them" likewise for a preprocessor or a language extension. none of these should require editing cabals code at all or require people to put something odd in their Setup.hs files to support the new compiler. perhaps what can be done for compiler support is to add a new 'common api' that newer compilers can use and a real --compiler option rather than the current --ghc --hugs hardcoded stuff. it should be just as easy as adding a specific hard-coded 'jhc' target and wouldn't feel so dirty. :) John -- John Meacham - ⑆repetae.net⑆john⑈

3 2

HackageDB: request for requests
by Ross Paterson 08 May '07

08 May '07

As you may know, Sascha Böhme will be doing a Google Summer of Code project on enhancing the (currently rather basic) web interface to HackageDB. There's a list of ideas at http://hackage.haskell.org/trac/hackage/wiki/HackageToDo Let's hear views on what's most important, what's missing, how it should be done, etc, but don't expect it all to get done this (northern-hemisphere) summer.

1 0

Test, please ignore
by Simon Marlow 08 May '07

08 May '07

I've had a report of difficulty posting to the list, so this is a test.

1 0

Why isn't Data.Map not an instance of Monoid :-)
by Adrian Hey 07 May '07

07 May '07

Hello Folks, Just been going through making sure the class instances for the AVL based Data.Map clone make sense, and I find this in Data.Map (and the clone). instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions This worries me because there is no obviously correct choice for the semantics of union for maps (as in which maps associated values get dropped). I've always felt that it was bad practice to provide library functions which simply make an arbitrary but a significant choice on users behalf, knowing it's likely that this isn't going to be what 50% of users actually want. So I'd been giving serious consideration to deprecating union, thereby forcing users to specify the behaviour they actually want using unionWith. The only reason I didn't in the end is that it's easy enough for users to get what they want in this case using flip (provided they don't care about "biasing" for keys) But it's not so easy if functions like this are used as class methods. So my inclination was to drop the Monoid instance for Maps. But I see by doing this I break Jean-Philippes instance of the Map class (which has a Monoid constraint) in the new Collections API.. http://darcs.haskell.org/packages/collections-ghc6.6/Data/Collections.hs AFAICT Jean-Philippe class only uses mempty, so I had been considering.. instance Ord k => Monoid (Map k v) where mempty = empty mappend = error "Data.Map.AVL: undefined Monoid.mappend." mconcat = error "Data.Map.AVL: undefined Monoid.mconcat." However, fooling people into thinking it is a Monoid when it isn't all so seems bad. So what do you think about this? Keep it or drop it? Does anybody (other than Jean-Philippe :-) currently rely on Data.Map being a Monoid instance? Regards -- Adrian Hey

2 2

why is Data.Set not a Monad?
by Frederik Eaton 07 May '07

07 May '07

Hello, Anyone know why Data.Set is not a Monad? Or Data.Map? It seems Data.Map is a Functor, but not Data.Set... I am confused. Am I not importing the right modules? Thanks, Frederik

5 6

StringBuffer.lhs (compiler/utils/) - hGetStringBuffer ? should the 'h' be there?
by Marc Weber 04 May '07

04 May '07

hPutStrLn etc all denote that you have to pass a handle hGetStringBuffer has the type hGetStringBuffer :: FilePath -> IO StringBuffer so I think the h is superfluous here ? Marc

1 0