January 2009 - Libraries

cabal usage
by Johannes Waldmann 08 Jan '09

08 Jan '09

what is the recommended way (fewest keystrokes) for: * cabal install foo (download from hackage) * build failure => edit sources => repeat install on modified sources Is it really "cabal fetch foo" then "tar xvfz ~/.cabal/some/very/long/pathname.tgz" ? during the original "cabal install", sources seem to be in /tmp/TMPfoo-*/* but they are removed on failure. or - is this a workflow that should not happen (e.g. it might lead to confusing error messages later because "ghc-pkg list" shows the original version number if I forget to bump it while patching the sources) J.W.

2 1

hsql[-mysql]
by Johannes Waldmann 08 Jan '09

08 Jan '09

can we fix the situation with hsql[-mysql]? it seems there are three versions, all named "-1.7", and none of them working with recent ghc: * http://htoolkit.sourceforge.net/ original project site * http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsql (build failures with ghc-6.8, 6.10) * http://code.haskell.org/HSQL/ current maintainer's site (build failures with 6.10) Since I needed this, I adapted the *.cabal and Setup.hs so they work with ghc-6.8 and 6.10. Since I posted this remark http://article.gmane.org/gmane.comp.lang.haskell.libraries/10299 I got several requests for these. So I'm making them available here provisionally (named *-1.7.1): http://dfa.imn.htwk-leipzig.de/~waldmann/draft/HSQL/ ... but of course this only adds to the confusion. best regards, J.W.

1 0

Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord
by Twan van Laarhoven 08 Jan '09

08 Jan '09

Hello list, About two and a half months ago I proposed that the following newtype (under the name "Down") be added to Data.Ord: newtype ReverseOrd a = ReverseOrd { getReverseOrd :: a } instance Ord ReverseOrd where a <= b = getReverseOrd b <= getReverseOrd a -- other methods, etc. I never followed up to that post, so I am doing that now. Since the discussion period has ended, let me summarize of responses: 1. Everyone is in favor of adding it 2. There is some criticism of the name 3. Some people (apfelmus) didn't like the getReverseOrd function As an alternative name, Isaac suggested "Reverse", "ReverseOrd" or "Opposite". I don't really like the name "Reverse", because that can mean many things: reversing a list, reverse order of composition, inverse/reverse a relation, etc. Although it is a bit verbose, "ReverseOrd" is the most clear. Concerning the "get" function: there is lots precedence in - Monoid wrappers (Sum, Product, Endo, etc.) - Applicative wrappers (ZipList, Const, etc.) - mtl types (State, Reader, etc.), To resolve the naming bikeshed issue, and because it has been a long time since the discussion ended, I propose an additional discussion period of 1 week, ending January 13. Twan

10 14

time package in the GHC build
by Ashley Yakeley 04 Jan '09

04 Jan '09

Can I remove the time package from the GHC build process? I want to update it but I don't want to deal with GHC's autotools stuff or break the GHC build. -- Ashley Yakeley

2 1

Endo-Monoid of lists = differences lists
by Henning Thielemann 03 Jan '09

03 Jan '09

How about a function for the Endo monoid, that lifts from a single value. toEndo :: (Monoid a) => a -> Endo a toEndo x = Endo (mappend x) For 'a' being a list type one would have a nice difference list. This may also occur in the documentation - both in the ones of Monoid.Endo and the of http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist . A similar application is Peano number with efficient addition. Would also be a nice type for ShowS.

1 0

blame: mtl MonadReader instance for ContT
by Nicolas Frisby 01 Jan '09

01 Jan '09

This mtl instance is in conflict with a usage of shift/reset that I'm porting from ML (Sheard's type-directed partial evaluator). > instance (MonadReader r' m) => MonadReader r' (ContT r m) where > local f m = ContT $ \c -> do > r <- ask > local f (runContT m (local (const r) . c)) I need to remove the "local (const r)" bit. I think this is just a different point in the diverse design space of dynamic binding/delimited control. Since Haskell lacks visibility management for importing instances, I'm forced to duplicate the rest of the ContT code in order to replace this instance with my own. 1) I am hoping this list can recall the reason for putting this design decision into the mtl. Perhaps there's a reason to prefer this particular side-effect interaction. 2) I am suggesting that the mtl be restructured such that this instance be delegated to a separate module so that i) I can avoid importing it along with the other useful instances ii) and the mtl could provide alternative instances. An alternative to breaking out the modules would be to not provide the instance. Another, more radical alternative could involve phantom types. I don't know of any in the mtl, but this same consideration might be applicable to other libraries with "arbitrary" instances.

4 5