- Libraries - Haskell.org

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

15 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 13 Oct '07

13 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 12 Oct '07

12 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 09 Oct '07

09 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

X11 package
by Don Stewart 07 Oct '07

07 Oct '07

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. -- Don

1 0

Proposal: Fix abstract unix sockets (#1699)
by Lennart Kolmodin 05 Oct '07

05 Oct '07

Hi, I've added proposal #1699 to fix abstract unix sockets on Linux for the network library. The patch is so far only tested under Linux (2.6.15), but should not affect Windows or other OSes which does not have AUS. >From the darcs patch comment: Abstract Unix Socket paths begin with a zero, are not zero terminated and needs accurate socklen calculation. Thus this patch, on linux: * Calculates the exact size of sockaddr. * Pokes sockaddr correctly wrt aus. Also, due to much more socklen usage: * Switch Network.Socket to use CSockLen instead of CInt. * Cleanup surrounding code. Cheers, Lennart Kolmodin -- "The only thing that interferes with my learning is my education." -- Albert Einstein

2 2

Control.Monad, Control.Applicative vs. Data.Foldable, Data.Traversable
by Henning Thielemann 01 Oct '07

01 Oct '07

What is the reason for some of the standard type classes being in 'Data' folder and some in 'Control'? Since, say 'Reader' is a monad, an applicative thing, an arrow and an instance of other classes - why is it located in Control.Monad? Why not Data.Reader? I find it reasonable to have a directory for concrete data types and one directory for classes. Currently I cannot see, why the Reader data type is in Monad, Monad is in Control, but Foldable class is in Data, together with List, Tree and other concrete data types.

1 0