March 2012 - Libraries

Re: [Haskell-cafe] haskell-platform vs macports
by Thomas Schilling 22 Mar '12

22 Mar '12

If you're not otherwise attached to MacPorts, you might want to check out Homebrew [1]. Its integration with the rest of OS X is generally more smoothly and I haven't come across any missing packages yet. [1]: http://mxcl.github.com/homebrew/ On 22 March 2012 16:34, Warren Harris <warrensomebody(a)gmail.com> wrote: > I assume that many haskell users out there on macs who are also users of macports, and I bet they've hit this same issue that I've hit numerous times. The problem is that there are 2 incompatible versions of libiconv -- one that ships with the mac, and one that's built with macports and that many macports-compiled libraries depend on. > > Work-arounds have been documented in numerous places (notably here: http://blog.omega-prime.co.uk/?p=96) but if you are trying to link with a macports-compiled libraries that depends on /opt/local/lib/libiconv.2.dylib, your only alternative seems to be building ghc from source in order to avoid the incompatibility. I hit this problem while trying to build a foreign-function interface to libarchive. > > So I built ghc from scratch -- in fact I built the whole haskell-platform. This was relatively painless, and fixed the libiconv problem. However, it brings me to the real point of my message, which is that the version of haskell-platform available via macports is way out of date (2009.2.0.2 http://www.macports.org/ports.php?by=name&substr=haskell-platform) > > I'm wondering whether the haskell-platform team has considered maintaining a macports version of the haskell-platform for us mac users in addition to the binary install that's available now. This would avoid the incompatibilities such as this nagging one with libiconv. Perhaps it's just a matter of maintaining template versions of the port files? > > Warren > > Undefined symbols for architecture x86_64: > "_locale_charset", referenced from: > _localeEncoding in libHSbase-4.3.1.0.a(PrelIOUtils.o) > "_iconv_close", referenced from: > _hs_iconv_close in libHSbase-4.3.1.0.a(iconv.o) > (maybe you meant: _hs_iconv_close) > "_iconv", referenced from: > _hs_iconv in libHSbase-4.3.1.0.a(iconv.o) > (maybe you meant: _hs_iconv, _hs_iconv_open , _hs_iconv_close ) > "_iconv_open", referenced from: > _hs_iconv_open in libHSbase-4.3.1.0.a(iconv.o) > (maybe you meant: _hs_iconv_open) > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status > cabal: Error: some packages failed to install: > Libarchive-0.1 failed during the building phase. The exception was: > ExitFailure 1 > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend.

1 0

Re: Bringing hs-plugins up to date
by Ben Gamari 21 Mar '12

21 Mar '12

On Mon, 19 Mar 2012 14:28:57 -0500, Jeremy Shaw <jeremy(a)n-heptane.com> wrote: > Does this actually work for you? It builds for me, but when readBinIface' > is called, it fails because the 'undefined' is apparently actually > evaluated in GHC 7.4.1. > Hmm, frankly this fix was to get another package dependent on plugins to compile (https://github.com/colah/ImplicitCAD) The program runs without evaluating undefined, but I suspect this is just because I haven't hit the relevant codepath. After a fairly brief look at the relevant documentation, I must say I don't see any easy solution to this. The undefined in question is a DynFlags. It seems that DynFlags.defaultDynFlags can give us a DynFlags, but unfortunately, it needs a Settings value (at least in 7.4), which has no obvious. It seems the correct way to do this is with parseDynamicFlags but, alas, this too requires a DynFlags. Cheers, - Ben

3 3

ANN: unification-fd 0.7.0
by wren ng thornton 19 Mar '12

19 Mar '12

-------------------------------------------- -- unification-fd 0.7.0 -------------------------------------------- The unification-fd package offers generic functions for single-sorted first-order structural unification (think of programming in Prolog, or of the metavariables in type inference)[1][2]. The library *is* sufficient for implementing higher-rank type systems a la [Peyton Jones, Vytiniotis, Weirich, Shields], but bear in mind that unification variables are the metavariables of type inference--- not the type-variables. An effort has been made to make the package as portable as possible. However, because it uses the ST monad and the mtl-2 package it can't be H98 nor H2010. However, it only uses the following common extensions which should be well supported[3]: Rank2Types MultiParamTypeClasses FunctionalDependencies -- Alas, necessary for type inference FlexibleContexts -- Necessary for practical use of MPTCs FlexibleInstances -- Necessary for practical use of MPTCs UndecidableInstances -- For Show instances due to two-level types -------------------------------------------- -- Changes (since 0.6.0) -------------------------------------------- This release is another major API breaking release. Apologies, but things are a lot cleaner now and hopefully the API won't break again for a while. The biggest change is that the definition of terms has changed from the previous: data MutTerm v t = MutVar !v | MutTerm !(t (MutTerm v t)) To the much nicer: data UTerm t v = UVar !v | UTerm !(t (UTerm t v)) The old mnemonic of "mutable terms" was inherited from the code's previous life implementing a logic programming language; but when I was playing around with implementing a type checker I realized that the names don't really make sense outside of that original context. So the new mnemonic is "unification terms". In addition to being a bit shorter, it should help clarify the separation of concerns (e.g., between unification variables vs lambda-term variables, type variables, etc.). The swapping of the type parameters is so that UTerm can have instances for Functor, Monad, etc. This change should've been made along with the re-kinding of variable types back in version 0.6.0, since the UTerm type is the free monad generated by t. I've provided all the category theoretic instances I could imagine some plausible reason for wanting. Since it's free, there are a bunch more I haven't implemented since they don't really make sense for structural terms (e.g., MonadTrans, MonadWriter, MonadReader, MonadState, MonadError, MonadCont). If you can come up with some compelling reason to want those instances, I can add them in the future. Since the order of type parameters to BindingMonad, UnificationFailure, Rank, and RankedBindingMonad was based on analogy to the order for terms, I've also swapped the order in all of them for consistency. I've removed the eqVar method of the Variable class, and instead added an Eq superclass constraint. Again, this should've happened with the re-kinding of variables back in version 0.6.0. A major benefit of this change is that now you can use all those library functions which require Eq (e.g., many of the set-theoretic operations on lists, like (\\) and elem). I've added new functions: getFreeVarsAll, applyBindingsAll, freshenAll; which are like the versions without "All", except they're lifted to operate over Foldable/Traversable collections of terms. This is crucial for freshenAll because it allows you to retain sharing of variables among the collection of terms. Whereas it's merely an optimization for the others (saves time for getFreeVarsAll, saves space for applyBindingsAll). The type of the seenAs function has also changed, to ensure that variables can only be seen as structure rather than as any UTerm. Thanks to Roman Cheplyaka for suggesting many of these changes. -------------------------------------------- -- Description -------------------------------------------- The unification API is generic in the type of the structures being unified and in the implementation of unification variables, following the two-level types pearl of Sheard (2001). This style mixes well with Swierstra (2008), though an implementation of the latter is not included in this package. That is, all you have to do is define the functor whose fixed-point is the recursive type you're interested in: -- The non-recursive structure of terms data S a = ... -- The recursive term type type PureTerm = Fix S And then provide an instance for Unifiable, where zipMatch performs one level of equality testing for terms and returns the one-level spine filled with pairs of subterms to be recursively checked (or Nothing if this level doesn't match). class (Traversable t) => Unifiable t where zipMatch :: t a -> t b -> Maybe (t (a,b)) The choice of which variable implementation to use is defined by similarly simple classes Variable and BindingMonad. We store the variable bindings in a monad, for obvious reasons. In case it's not obvious, see Dijkstra et al. (2008) for benchmarks demonstrating the cost of naively applying bindings eagerly. There are currently two implementations of variables provided: one based on STRefs, and another based on a state monad carrying an IntMap. The former has the benefit of O(1) access time, but the latter is plenty fast and has the benefit of supporting backtracking. Backtracking itself is provided by the logict package and is described in Kiselyov et al. (2005). In addition to this modularity, unification-fd implements a number of optimizations over the algorithm presented in Sheard (2001)--- which is also the algorithm presented in Cardelli (1987). * Their implementation uses path compression, which we retain. Though we modify the compression algorithm in order to make sharing observable. * In addition, we perform aggressive opportunistic observable sharing, a potentially novel method of introducing even more sharing than is provided by the monadic bindings. Basically, we make it so that we can use the observable sharing provided by the modified path compression as much as possible (without introducing any new variables). * And we remove the notoriously expensive occurs-check, replacing it with visited-sets (which detect cyclic terms more lazily and without the asymptotic overhead of the occurs-check). A variant of unification which retains the occurs-check is also provided, in case you really need to fail fast. * Finally, a highly experimental branch of the API performs *weighted* path compression, which is asymptotically optimal. Unfortunately, the current implementation is quite a bit uglier than the unweighted version, and I haven't had a chance to perform benchmarks to see how the constant factors compare. Hence moving it to an experimental branch. These optimizations pass a test suite for detecting obvious errors. If you find any bugs, do be sure to let me know. Also, if you happen to have a test suite or benchmark suite for unification on hand, I'd love to get a copy. -------------------------------------------- -- Notes and limitations -------------------------------------------- [1] At present the library does not appear amenable for implementing higher-rank unification itself; i.e., for higher-ranked metavariables, or higher-ranked logic programming. To be fully general we'd have to abstract over which structural positions are co/contravariant, whether the unification variables should be predicative or impredicative, as well as the isomorphisms of moving quantifiers around. It's on my todo list, but it's certainly non-trivial. If you have any suggestions, feel free to contact me. [2] At present it is only suitable for single-sorted (aka untyped) unification, a la Prolog. In the future I aim to support multi-sorted (aka typed) unification, however doing so is complicated by the fact that it can lead to the loss of MGUs; so it will likely be offered as an alternative to the single-sorted variant, similar to how the weighted path-compression is currently offered as an alternative. [3] With the exception of fundeps which are notoriously difficult to implement. However, they are supported by Hugs and GHC 6.6, so I don't feel bad about requiring them. Once the API stabilizes a bit more I plan to release a unification-tf package which uses type families instead, for those who feel type families are easier to implement or use. There have been a couple requests for unification-tf, so I've bumped it up on my todo list. -------------------------------------------- -- References -------------------------------------------- Luca Cardelli (1987) /Basic polymorphic typechecking/. Science of Computer Programming, 8(2):147--172. Atze Dijkstra, Arie Middelkoop, S. Doaitse Swierstra (2008) /Efficient Functional Unification and Substitution/, Technical Report UU-CS-2008-027, Utrecht University. <http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-027.pdf> Simon Peyton Jones, Dimitrios Vytiniotis, Stephanie Weirich, Mark Shields /Practical type inference for arbitrary-rank types/, to appear in the Journal of Functional Programming. (Draft of 31 July 2007.) Oleg Kiselyov, Chung-chieh Shan, Daniel P. Friedman, and Amr Sabry (2005) /Backtracking, Interleaving, and/ /Terminating Monad Transformers/, ICFP. <http://www.cs.rutgers.edu/~ccshan/logicprog/LogicT-icfp2005.pdf> Tim Sheard (2001) /Generic Unification via Two-Level Types/ /and Paramterized Modules/, Functional Pearl, ICFP. <http://web.cecs.pdx.edu/~sheard/papers/generic.ps> Tim Sheard & Emir Pasalic (2004) /Two-Level Types and/ /Parameterized Modules/. JFP 14(5): 547--587. This is an expanded version of Sheard (2001) with new examples. <http://web.cecs.pdx.edu/~sheard/papers/JfpPearl.ps> Wouter Swierstra (2008) /Data types a la carte/, Functional Pearl. JFP 18: 423--436. <http://www.cs.ru.nl/~wouters/Publications/DataTypesALaCarte.pdf> -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/unification-fd Darcs: http://community.haskell.org/~wren/unification-fd Haddock (Darcs version): http://community.haskell.org/~wren/unification-fd/dist/doc/html/unification… -- Live well, ~wren

1 0

Bringing hs-plugins up to date
by Ben Gamari 18 Mar '12

18 Mar '12

Here are a few patches to get hs-plugins compiling again on GHC 7.4.1. The first I stole from Brian Victor[1], while the second simply replaces addrToHValue# with addrToAny# (a change apparently made in 7.4). There are active codebases that rely on this package so it would be appreciated if someone could push a new release of plugins with these applied. Thanks! Cheers, - Ben [1] http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/95185 P.S. Sorry, my darcs-fu isn't particluarly strong, so I ended I having to edit the patches by hand to separate the changes. Hopefully they'll still apply on your end. diff -rN -u old-hs-plugins/src/System/Plugins/Load.hs new-hs-plugins/src/System/Plugins/Load.hs --- old-hs-plugins/src/System/Plugins/Load.hs 2012-03-04 22:52:59.049531108 -0500 +++ new-hs-plugins/src/System/Plugins/Load.hs 2012-03-04 22:52:59.221531962 -0500 @@ -84,9 +84,15 @@ import System.Directory ( doesFileExist, removeFile ) import Foreign.C.String ( CString, withCString, peekCString ) +#if !MIN_VERSION_ghc(7,2,0) import GHC ( defaultCallbacks ) +#endif import GHC.Ptr ( Ptr(..), nullPtr ) #if DEBUG @@ -99,7 +105,11 @@ readBinIface' :: FilePath -> IO ModIface readBinIface' hi_path = do -- kludgy as hell +#if MIN_VERSION_ghc(7,2,0) + e <- newHscEnv undefined +#else e <- newHscEnv defaultCallbacks undefined +#endif initTcRnIf 'r' e undefined undefined (readBinIface IgnoreHiWay QuietBinIFaceReading hi_path) -- TODO need a loadPackage p package.conf :: IO () primitive @@ -679,7 +693,11 @@ -- and find some packages to load, as well. let ps = dep_pkgs ds +#if MIN_VERSION_ghc(7,2,0) + ps' <- filterM loaded . map packageIdString . nub $ map fst ps +#else ps' <- filterM loaded . map packageIdString . nub $ ps +#endif #if DEBUG when (not (null ps')) $ diff -rN -u old-hs-plugins/src/System/Plugins/Load.hs new-hs-plugins/src/System/Plugins/Load.hs --- old-hs-plugins/src/System/Plugins/Load.hs 2012-03-04 22:53:01.073541145 -0500 +++ new-hs-plugins/src/System/Plugins/Load.hs 2012-03-04 22:53:01.229541919 -0500 @@ -84,9 +84,15 @@ import GHC.Ptr ( Ptr(..), nullPtr ) +#if !MIN_VERSION_ghc(7,4,1) import GHC.Exts ( addrToHValue# ) +#else +import GHC.Exts ( addrToAny# ) +#endif import GHC.Prim ( unsafeCoerce# ) #if DEBUG @@ -445,7 +455,11 @@ ptr@(Ptr addr) <- withCString symbol c_lookupSymbol if (ptr == nullPtr) then return Nothing +#if !MIN_VERSION_ghc(7,4,1) else case addrToHValue# addr of +#else + else case addrToAny# addr of +#endif (# hval #) -> return ( Just hval )

1 0

remove Foreign.Marshal.Error.void
by Evan Laforge 18 Mar '12

18 Mar '12

So now that we have void in Control.Monad, can we remove it from Foreign.Marshal.Error? Or at least make them the same function? It's mildly annoying when importing both Control.Monad and Foreign winds up with ambiguous symbol errors.

3 4

Re: LProposal: add traverseWithKey to Data.Map
by John Lato 15 Mar '12

15 Mar '12

> From: Max Bolingbroke <batterseapower(a)hotmail.com> > > Hi Haskellers, > > I propose to add a new function, traverseWithKey, to Data.Map: > +1 Does it make sense to additionally add traverseWithKey to Data.IntMap? John L.

2 1

Proposal: System.Environment.getEnv should return Maybe
by Evan Laforge 14 Mar '12

14 Mar '12

It's awkward and surprising how getEnv throws an exception when an env var is not set, since it's very common for env vars to be optional, and it's not convenient to catch exceptions in haskell (I have to look up Control.Exception every time, and then add LANGUAGE ScopedTypeVariables). I wind up using 'fmap lookup k Environment.getEnvironment' instead. So I propose a function: lookupEnv :: String -> IO (Maybe String) Then getEnv can be deprecated and eventually removed. Or maybe not if people want to argue the current getEnv is useful and deprecation warnings would be too annoying. Yeah, it's a trivial thing, but it's nice to sand off some of these rough edges. Discussion: 2 weeks, March 7

16 20

Generics and data families
by Reiner Pope 14 Mar '12

14 Mar '12

Hi all, The DeriveGeneric language extension in ghc 7.4 does not support data families, so the following will not compile: > data family D a > data instance D Int = DInt deriving Generic > data instance D Bool = DBool deriving Generic On http://hackage.haskell.org/trac/ghc/ticket/5936, I provided a patch for ghc which makes the above compile, giving the (approximately) the following instances for Rep and Generic: > type instance Rep (D Int) = D1 DIntInfo_D (C1 DIntInfo_C U1) > type instance Rep (D Bool) = D1 DBoolInfo_D (C1 DBoolInfo_C U1) > > instance Generic (D Int) where ... > instance Generic (D Bool) where ... Note in particular that D Int and D Bool are considered completely distinct types as far as generics are concerned. Is this the right approach to take to handle generics for data families? Are there alternative approaches? On the Trac ticket linked above, Pedro suggested we discuss these questions here. Regards, Reiner

2 2

Re: Proposal: System.Environment.getEnv should return Maybe
by John Lato 13 Mar '12

13 Mar '12

> From: Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> > > Brandon Allbery <allbery.b(a)gmail.com> writes: > >> On Wed, Feb 22, 2012 at 18:51, John Meacham <john(a)repetae.net> wrote: >> >>> On Wed, Feb 22, 2012 at 3:05 PM, Evan Laforge <qdunkan(a)gmail.com> wrote: >>> > It's awkward and surprising how getEnv throws an exception when an env >>> > var is not set, since it's very common for env vars to be optional, >>> > and it's not convenient to catch exceptions in haskell (I have to look >>> >>> For true IO exceptions, you should be using the Prelude.catch mechanism. >>> >> >> This still assumes that it's an exceptional condition that is being >> modeled. It is not; it is correctly modeled as a Maybe. > > +1. And it?s always irritated me that read at EOF raises an > exception. Files having ends is not exceptional! (This is partly > addressed by iteratees, I imagine, but I haven?t found time to > get my head round those yet.) This irritates me too; I don't think that Haskell exceptions should be used for much of anything, exceptional condition or not. +1 for the proposal. Also, the unix-bytestring package (http://hackage.haskell.org/package/unix-bytestring) exposes IO functions that don't raise exceptions at EOF. John L.

5 8

Re: Proposal: System.Environment.getEnv should return Maybe
by John Lato 12 Mar '12

12 Mar '12

> Currently there is no one planning to use MaybeT in System.Environment, > since this would mean to make base/haskell2010 depend on transformers. But > an option might be to start a package where generally IO exceptions are > replaced by MaybeT and its friends. Then we could leave System.Environment > as it is. But people don't want to leave System.Environment as it is. That was the point of the proposal, which does have widespread support (IIRC nobody spoke in defense of the current behavior). And as you point out, using MaybeT in System.Environment is currently a non-starter, which makes IO (Maybe String) the obvious type choice regardless of use case. The proposal didn't go through the entire chain of reasoning there, but I would expect it's obvious to everyone involved in the discussion. In my support of the proposal, I tossed in a (probably ill-advised) comment expressing my dislike of implicit exceptions in general, which I have to say I now regret. I certainly don't want this proposal, which has universal support, to become bogged down in a discussion about implicit exceptions in general. Especially since the general discussion seems to have little to add to the specifics of this particular proposal. With apologies, John L.

1 0