October 2007 - Libraries

CPP confusion
by Duncan Coutts 17 Oct '07

17 Oct '07

All, There seems to me to be a great deal of confusion with CPP options in Haskell land. We apply the same cpp options to C code and to Haskell code, and there are other tools like pre-processors which make things even more confusing. The latest thing I've stumbled over is HsUnix.h in ghc-6.8. This header file is for defines to use when pre-processing Haskell code. It used to live in the global $GHCLIBDIR/include but now lives in the include dir for the unix package. This is probably the right thing to do, however... How do packages that want to use this include actually use it? If they #include it directly in a .hs file then it'll work since ghc -package unix adds the unix package's include dir to the search path. But what if someone needs to use it in a .hsc file? Well, then it does not work. It does not work because Cabal does not pass these include directories to hsc2hs, since we've relied on ghc to do that. But obviously that does not work for hsc2hs. As it happens the fork of hsc2hs that ghc comes bundled with uses ghc as it's C compiler, so we could in fact pass hsc2hs --cflag=-package --cflag=unix then it does work because hsc2hs ends up passing ghc -package unix and then ghc adds the unix's include dir to the search path when it goes on to call gcc to actually compile the C code. Yay, for many layers of confusion. So what is the solution? We could take advantage of the fact that we know that hsc2hs really uses ghc as it's C compiler and change the flags we pass it when we happen to be building with ghc. On the other hand this all becomes non-portable. In fact this totally relies on a package database to remember what search directories to use when pre-processing dependent packages. In other words it only has a chance of working with ghc at the moment, or nhc in future if/when it implements a package database. What to do? Short and long term suggestions please. Duncan

3 2

Support for high baud rates in the serial binding
by Don Stewart 16 Oct '07

16 Oct '07

The attached patch adds support for higher baud rates to System.Posix.Terminal. We need this in practice, so it would be nice to get this into stable. Its a trivial change. -- Don

1 0

Re: [Haskell-cafe] Let's do ListT right, finally
by David Menendez 14 Oct '07

14 Oct '07

On 10/14/07, Dan Piponi <dpiponi(a)gmail.com> wrote: > On 10/14/07, Yitzchak Gale <gale(a)sefer.org> wrote: > > Not very much, I suspect. That "monad" really is broken - > > it's not a monad at all. > > Depending on your point of view, ListT isn't broken. It correctly > transforms commutative monads into monads. The problem is that you > can't express "commutative monad" any differently from "monad" in > Haskell. And so it's been shoehorned into the wrong type class. If desired, we could easily define a class for commutative monads, and then state that ListT m is only a monad if m is a commutative monad. For example, class Monad m => CommutativeMonad m instance (CommutativeMonad m) => Monad (ListT m) where return a = ListT (return [a]) etc. Naturally, it's up to the programmer to guarantee that instances of CommutativeMonad are actually commutative monads. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

2 1

Re: [Haskell-cafe] Let's do ListT right, finally
by Yitzchak Gale 14 Oct '07

14 Oct '07

Hi Dan, I wrote: >> That "monad" really is broken - it's not a monad at all. Dan Piponi wrote: > Depending on your point of view, ListT isn't broken. It correctly > transforms commutative monads into monads. Interesting. What do you mean by a "commutative monad"? It can't be a monad with some sort of additional commutative law, because the old ListT doesn't even satisfy the monad laws. Or does it in some sense? > The replacement ListT is usually the monad transformer > I need when I want a List-like monad transformer, > so I'm all for it being in (the standard prelude) mtl. OK. I take this as a +1 vote for the rewrite. > But it seems sad there isn't a place for the old one > to live. OK, do you propose that we keep it and change its name? -Yitz

1 0

runInteractiveProcess and buffering
by Henning Thielemann 13 Oct '07

13 Oct '07

It looks like my problem has to do with buffering, but I don't know how to solve it. main :: IO () main = do (inp,out,err,pid) <- runInteractiveProcess "aseqdump" ["-p", "72:0"] Nothing Nothing hSetBuffering out NoBuffering hGetBuffering out >>= print hGetLine out >>= putStrLn return () The data of 'out' seems to be buffered, because 'aseqdump' must produce many lines until even the first one is returned by 'hGetLine' and printed by 'putStrLn'. I tried to disable buffering for 'out' and indeed 'NoBuffering' is printed to the terminal, but the output from 'aseqdump' is still deferred.

2 3

Trying to install binary-0.4
by Paul Johnson 13 Oct '07

13 Oct '07

In my copious free time I'm putting together a client-side library for AMQP. This needs efficient packing of bytestrings, so I downloaded Dons' bytestring 0.4. Unfortunately it won't install: I get [paj@eiffel binary-0.4]$ ./Setup.lhs configure Configuring binary-0.4... configure: Dependency base-any: using base-2.1.1 Setup.lhs: cannot satisfy dependency containers-any Should this be "collections" not "containers"? I can't find a "containers" package in Hackage. Paul.

5 6

X11 1.2.3 released
by Don Stewart 12 Oct '07

12 Oct '07

A new release of X11, ready for ghc 6.8, (and the upcoming xmonad release), is on hackage, and tagged in darcs: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-1.2.3 Main change is Ross fixed the Setup.hs file to not use wacky hooks. Future plans are to merge the X11-extras (aka Xinerama bindings) into X11, for the next release. -- Don

1 0

Re: X11 package
by Don Stewart 11 Oct '07

11 Oct '07

ketil: > Don Stewart <dons(a)galois.com> writes: > > > I've taken over maintainership of the X11 package, as we need it for > > xmonad. The previous maintainer was libraries@. Let me know if you've > > any problems with this. > > Absolutely not! Thanks for doing this. Mind taking over Parsec as > well? :-) > Overwhelming support :) Consider X11 owned. -- Don

1 0

Fwd: Suitable new name for Dimensional library
by Björn Buckwalter 09 Oct '07

09 Oct '07

On 9/28/07, Henning Thielemann <lemming(a)henning-thielemann.de> wrote: > > On Thu, 27 Sep 2007, Björn Buckwalter wrote: > > > Secondly, I feel that "Dimensional" is to vague and ambiguous, in > > particular it could just as well refer to dimensions in the linear > > algebra sense as physical dimensions. I'd like a more specific and > > perhaps less pretentious name for the library. This is where I would > > appreciate some feedback as to what would be appropriate. Some > > suggestions are: > > > > - Numeric.Units > > - Numeric.PhysicalUnits > > - Numeric.PhysicalDimensions > > - Numeric.SI > > - Numeric.SIUnits > > - Numeric.Units.Static > > It's certainly a good idea to distinguish between static and dynamic > implementations. Incidentally, my implementation of numbers with units > uses dynamic unit checking. It is also implemented in a generic way for > any unit system, but has a specialisation for SI units. Currently it does > not adhere to standard top-level module names (which are these and why?) > but this could be changed. >From the wiki[1] it appears there is no standard, only three proposals (which all have 'Numeric' at the top-level). [1] http://www.haskell.org/haskellwiki/Applications_and_libraries#Guidelines_fo… > I use: > > Number/Physical.hs > Number/Physical/Read.hs > Number/Physical/Show.hs > Number/Physical/Unit.hs > Number/Physical/UnitDatabase.hs > Number/SI.hs > Number/SI/Unit.hs > > To be compatible with your library, the module names should contain some > hint to their dynamic nature. And conversely by this argument my module names should contain some hint to their static nature, under the assumption that you (or somewhen else) will eventually move a "dynamic" unit library to the 'Numeric' namespace. A suitable namespace would be 'Numeric.Units.Static'. Taken further though, if someone develops another "static" unit library where should they put it? An arbitrarily complex tree of namespaces could be built trying to distinguish libraries to anticipate future clashes. This leads me to wonder -- is it better for a library to have a more or less arbitrary differentiating name rather than a descriptive name? Examples are 'Text.ParserCombinators.Parsec', 'Text.Parsers.Frisby'. >From their names it's not obvious what distinguishes them from other parsers in the same namespace but at least the tree is fairly flat and hopefully narrowed down enough to permit investigating each alternative. In the units case I imagine 'Numeric.Units.SomethingArbitrary' would be appropriate. As counterexamples I also notice there are cases where a library has a unique name but still a very generic namespace, e.g. Takusen which uses 'Database', Haifa with among other 'Text.XML.Serializer'. Then there is HAppS which at a cursory glance appears to use 'HAppS' as its top-level namespace, which has the obvious advantage of not having to worry about other libraries in the same namespace while also keeping the rather broad HAppS code collected in one place. Comments on what is appropriate (for my case, not necessarily for all cases)? I'm still leaning towards 'Numeric.Units' or something thereunder. Thanks, Bjorn

2 2

Hackage and GHC 6.8
by Don Stewart 08 Oct '07

08 Oct '07

Neil Davies wrote: > Given that GHC 6.8 is just around the corner and, given how it has > re-organised the libraries so that the dependencies in many (most/all) > the packages in the hackage DB are now not correct. > > Is there a plan of how to get hackage DB up to speed with GHC 6.8 ? Ian, GHC HQ, can you elaborate on what the plan is on fixing the hackage libraries for ghc 6.8 -- should everyone be springing into action to update .cabal files and fix api changes? -- Don

5 6