October 2006 - Libraries

Where is Distribution.Compat.FilePath in Cabal-1.1.6?
by Bayley, Alistair 24 Oct '06

24 Oct '06

It appears that in Cabal-1.1.6, Distribution.Compat.FilePath is hidden (I don't have it installed, just a complaint from a user trying to install Takusen with ghc-6.6). I had a look around and found this message: http://www.haskell.org/pipermail/cabal-devel/2006-September/000165.html which says to me that it ought to be exposed. What's happened here? Has it moved somewhere else, or is it unintentionally hidden? FWIW, I'm using just the splitFileName and joinPaths functions, so if there are equivalents somewhere else that I ought to be using, I'd love to know. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 2

TArray.hs
by Taral 24 Oct '06

24 Oct '06

I see TArray is in the libraries, but I note that I posted a version that uses newTVarIO for efficiency a while back. I have attached it, and you are welcome to include it in the GHC distribution. -- Taral <taralx(a)gmail.com> "You can't prove anything." -- Gödel's Incompetence Theorem

1 0

proposed addition to System.IO
by Ross Paterson 23 Oct '06

23 Oct '06

I propose adding the following functions to System.IO: -- | @'withFile' name mode act@ opens a file using 'openFile' and passes -- the resulting handle to the computation @act@. The handle will be -- closed on exit from 'withFile', whether by normal termination or by -- raising an exception. withFile :: FilePath -> IOMode -> (Handle -> IO r) -> IO r withFile name mode = bracket (openFile name mode) hClose -- | @'withBinaryFile' name mode act@ opens a file using 'openBinaryFile' -- and passes the resulting handle to the computation @act@. The handle -- will be closed on exit from 'withBinaryFile', whether by normal -- termination or by raising an exception. withBinaryFile :: FilePath -> IOMode -> (Handle -> IO r) -> IO r withBinaryFile name mode = bracket (openBinaryFile name mode) hClose (bracket is the one from Control.Exception, if available, else the one from System.IO.Error) These functions are close to the Fairbairn Threshold, but just above it, I think, and worth naming because they wrap up a pattern that should be encouraged.

2 1

darcs patch: Documentation for Data.Monoid.Endo (untested because m...
by Samuel Bronson 23 Oct '06

23 Oct '06

Mon Oct 23 14:30:08 EDT 2006 Samuel Bronson <naesten(a)gmail.com> * Documentation for Data.Monoid.Endo (untested because my haddock doesn't like the --source-module flag)

1 0

darcs patch: Add UTF8 converting and outputing functions
by mukai＠jmuk.org 22 Oct '06

22 Oct '06

Thu Oct 12 22:55:03 JST 2006 mukai(a)jmuk.org * Add UTF8 converting and outputing functions In GHC 6.6, the source code can include UTF-8 characters and converted them to Unicode chars. However, there are no (easy) way to convert them from/to UTF-8 in standard libraries of GHC. When outputing unicode characters in current GHC, hPutChar overflows their codepoints, and just prints lower 8-bit. This has not been a serious problem because past haskell programs contained few unicode characters. By now, the codes containing unicode characters become widespread because of supporting UTF-8 encoding. Therefore, base library must have some ways to deal with this problem, IMHO. Best regards, Jun Mukai mukai(a)jmuk.org

8 8

GHC 6.6 Data.Tuple incompatibility
by John Goerzen 20 Oct '06

20 Oct '06

Hello, I had this code that worked in GHC 6.4: type CommandHandler = FTPServer -> String -> IO Bool type Command = (String, (CommandHandler, (String, String))) instance Eq Command where x == y = (fst x) == (fst y) instance Ord Command where compare x y = compare (fst x) (fst y) I am compiling with overlapping instances set. In GHC 6.6, this gives an error that Eq Command is a duplicate instance of one defined in Data.Tuple. Commenting out that instance causes the Ord Command instance to fail because there is no Eq instance for CommandHandler. After discussing it with Ian Lynagh, his conclusion was that the problem is that Data.Tuple was not compiled with overlapping instances support, and that it probably ought to be. He asked me to post here to see if everyone else felt the same way. Thanks, -- John

6 6

problems with Control.Applicative
by John Meacham 20 Oct '06

20 Oct '06

I really like the ideas behind Control.Applicative, but find it troublesome to use in practice. mainly, the minimalist choice of what to make class methods makes it very difficult to use for various applications. an example that is bugging me right now is that it is the _perfect_ fit for my frisby parser generator, however, I am unable to use it because the primitives 'pure' and 'fmap' and '<*>' which Control.Applicative is built on are not suitable low level primitives in practice (despite being sufficient in theory). The basic issue is that frisby relys on optimizing the parser before executing it, so any static information that can be gleaned from the built parser is very important to have available. however, the optimizer has no way to "see through" an 'fmap' since the functional argument is opaque as far as frisby is concerned. the rub is plain old fmap is almost never used, but all the useful things Control.Applicative provides are: in particular: (<$) :: Functor f => a -> f b -> f a (*>) :: Applicative f => f a -> f b -> f b (<*) :: Applicative f => f a -> f b -> f a optional :: Alternative f => f a -> f (Maybe a) some :: Alternative f => f a -> f [a] many :: Alternative f => f a -> f [a] (along with pure) are sufficient to encode pretty much every reasonable parser, and all of them have a special internal representation independent of 'fmap' it is rather disapointing that I can't make use of this library as it is in ghc when it is such a good fit for the application. Perhaps in the next revision we can move these (or a suitable subset) functions into the class? note I don't really consider RULES appropriate here, knowing that the optimizer will be able to see through these operations is vital for writing a parser that works at all. I would also like to see mapM_ as part of the class definition for traversable. For many monads it makes the difference between linear and constant space usage and space behavior of haskell programs is hard enough to reason about without having to worry about certain rules firing. Also, relying on rules means not being able to use polymorphic combinators built upon these primitives without taking special steps to ensure the rules can still fire. I really like the ideas behind Applicative,Traversable, and Foldable. but I feel these issues will unecesarrily hurt their utility. John -- John Meacham - ⑆repetae.net⑆john⑈

3 5

requesting specific Cabal version
by Bulat Ziganshin 17 Oct '06

17 Oct '06

Hello Haskell, what about adding to .cabal file ability to ask for specific Cabal version? it will allow to make incompatible changes between Cabal versions. program that uses services specific to Cabal 1.4.x, for example, will just ask for using this Cabal version and operation will go fine of course, it will require to have cabal 1.4.x, 1.6.x and other versions simultaneously installed - just like now it's possible (in ghc) to have different versions of any other lib installed together -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

What's the story re. darcs.haskell.org?
by Adrian Hey 15 Oct '06

15 Oct '06

Hello folks, These may be dumb questions, but I'm afraid I haven't been keeping up with what's happening in the Haskell world recently.. So.. Is darcs.haskell.org the recommended place to start a new project? If so, who owns/runs this machine and how do I get access to it? What's the rationale for it's current organisation e.g. why is there a separate "packages" directory? (There seem to be packages elsewhere) and what's the "packages.hide" directory for? Thanks -- Adrian Hey

6 8

darcs patch: UNDO: Inline shift in GHC's Bits instanc... (and 1 more)
by Samuel Bronson 12 Oct '06

12 Oct '06

Sun Oct 8 22:09:06 EDT 2006 Samuel Bronson <naesten(a)gmail.com> UNDO: Inline shift in GHC's Bits instances for {Int,Word}{,8,16,32,64} Goes with my inliner patch. Thu Oct 12 08:55:53 EDT 2006 Samuel Bronson <naesten(a)gmail.com> * Use unchecked shifts to implement Data.Bits.rotate This should get rid of those cases, maybe lower the size enough that the inliner will like it? Should make Data.Bits.rotate much more attractive to the inliner, especially for Word types. (Zaps two redundant cases, *and* gets rid of all lets for Word types. Unfortunately the Int types still have lets for the call to int2Word#... probably this is not good, since that doesn't actually do work!)

1 0