December 2012 - Libraries

Re: Proposal: merge Data.Functor.Coproduct into transformers
by wren ng thornton 17 Dec '12

17 Dec '12

On 12/17/12 7:13 AM, Ben Millwood wrote:> On Mon, Dec 17, 2012 at 2:39 AM, wren ng thornton <wren(a)freegeek.org> wrote: >> On 12/16/12 9:36 AM, Andreas Abel wrote: >>> >>> Standing up against the dictator... >>> >>> I like neither 'Product' nor 'Sum'. For one, they are ambiguous already >>> in type theory. >> >> Yeah, this is one of the reasons I prefer Coproduct (or EitherF, or >> Either1). FWIW, I wrote a short blog post about this terminological >> confusion some time back: >> >> http://winterkoninkje.dreamwidth.org/72346.html > > Hmm. As I always understood it, the confusion was because [...] I'm not entirely sure I'd call it "a confusion" in type theory; it's really more of a clash of traditions/perspectives. The confusion is what arises in newcomers first encountering this discrepancy. As for sigma types being similar to disjoint unions, that's only if we consider type tags to be literally part of the data. While that's a feasible perspective, I'm not sure it's the most perspicuous one. The thing is, we have both a family of adjunctions between products and exponentials: (a*_) --| (_^a) as well as an adjunction chain relating coproducts to products: (_+_) --| \diag --| (_*_) However, these result in conflicting notions of duality for products. The set-theoretic terminology highlights the former adjunctions, whereas the functional-programming terminology highlights the latter adjunctions. Even if you can encode colimits with limits in a particular category, I wouldn't say they're the same thing. In certain lattices we can encode meets with joins (and vice versa), but noone would say those're the same operation. -- Live well, ~wren

1 0

Proposal: merge Data.Functor.Coproduct into transformers
by Mario Blazevic 17 Dec '12

17 Dec '12

At the instigation of Edward Kmett, I hereby propose to merge Data.Functor.Coproduct module from comonad-transformers into transformers. The module defines the Coproduct data type, together with several class instances. All non-base instances would have to be left out, leaving the following instances to be merged in: instance (Functor f, Functor g) => Functor (Coproduct f g) instance (Foldable f, Foldable g) => Foldable (Coproduct f g) instance (Traversable f, Traversable g) => Traversable (Coproduct f g) Unfortunately, the Applicative and Monad instances cannot be defined on this type, though their duals can. In that sense, the existing comonad-transformers package is a more fitting home for the type. However, there are good reasons for the move: - The dual type of Coproduct, namely Data.Functor.Product, is already defined by transformers. It would make sense to keep the duals together. - Data.Functor.Compose and Data.Functor.Constant which also defined by transformers are not monads either, so there is precedent for having non-monads there. - Most obviously, transformers is a haskell-platform package while comonad-transformers seems unlikely to become one any time soon (as much as I'd like that). - The existing Comonad instance can be moved from comonad-transformers to comonad; it would not be orphaned. The patch against the darcs repository is attached. An alternative naming for the module (and the type) would be Data.Functor.Sum. This name would be shorter and less frightening to newcomers, but it clashes with its namesake type from Data.Monoid. On the other hand, so does Data.Functor.Product. I'm ambivalent on the naming, but I'm throwing this out because I don't expect it to become a bikeshed issue. If you have any name preference, state it together with your vote; if the proposal succeeds we can use whichever name is preferred.

14 27

Data.IntMap.Strict.findWithDefault is too strict
by Christian Maeder 17 Dec '12

17 Dec '12

Hi, when trying out Data.IntMap.Strict instead of Data.IntMap, I've noticed (after some confusion) that Data.IntMap.Strict.findWithDefault evaluates the default value, even if it is not used! I usually pass an error-call to IntMap.findWithDefault to get a more informative crash-message than by using IntMap.! Evaluating (error "...") surely crashes, but the evaluation should only happen when the key is not in the map! I can easily work around this (by using fromMaybe and IntMap.lookup), but it is still worth at least being documented if crucial for performance. (the same applies to Data.Map) Cheers Christian

7 16

transformers: instance MonadTrans Compose
by Henning Thielemann 16 Dec '12

16 Dec '12

What about this instance: module Data.Functor.Compose import Control.Monad.Trans.Class (MonadTrans, lift) instance (Monad f) => MonadTrans (Compose f) where lift x = Compose (return x) ? The constraint (Monad f) is ugly. An (Applicative f) may not fit to a *Monad*Trans class. On the other hand, Compose is more oftenly used to compose Applicative functors.

2 1

RFC: Can DefaultSignature compile-time conditional APIs be regarded "benign"?
by Herbert Valerio Riedel 14 Dec '12

14 Dec '12

Dear List, After recent discussions[1][2], from which I gathered that (compile-time) conditional APIs should be avoided, I'm left wondering if a certain kind of compile-time conditional API falls into that category as well, or whether it can be classified as "benign" and should therefore be tolerated. So I'm posting this for open discussion in the hope to reach a community consensus on whether the conditional use of the "DefaultSignature" language extension in APIs should be tolerated or not (e.g. for haskell-platform packages). To this end, in the rest of this post I try to make a case for why this class of conditional APIs is harmless. ----- So what's bad about "conditional" APIs? The way I understand the issue with respect to compile-time conditional APIs which either a) omit exposed modules or exported symbols altogether based on compile-time configuration, or even worse b) export different type-signatures for the very same symbol based on compile-time configuration are "bad", as they cause problems in client code using those APIs, such as a) not being able to properly declare the dependency on specific API features being enabled in the library API in CABAL files (since CABAL only allows to depend package version numbers), b) and from the other direction, there's no simple way for the library package to advertise the conditional features currently present in the registered package. c) Moreover, if the client code wants to use symbols which depend on compile-time configuration, it either becomes non-portable and/or becomes compile-time conditional itself. Note: It should be stressed that in the latter case the client code needs to take care to *exactly* replicate the semantics of the conditional switching between the API variants as employed by the library code (which can be CPP-based and/or CABAL-based), as any mismatch may result in compile time failures. This also poses the issue on how to properly document this "meta-property" in the library API documentation. (there may be more reasons, I just listed the ones off the top of my head) On the other hand, I think that there are cases, when a compile-time conditional API is "benign", for instance when the following condition holds: a) the library package exposes a /non-essential/ API feature based only on availability of a given compiler-feature/extension, b) the conditional feature is only ever visible to the client code if the client makes use of this compiler-feature itself, and last but not least c) the semantics of the client code must not change if the client code has been made portable (with respect to the availability of the conditional feature) E.g. consider the following hypothetical class definition: class Size a where size :: a -> Int #ifdef HAS_DEFAULT_SIGNATURE default size :: Generic a => a -> Int size x = ...Generics based implementation... #endif Now, if the client code doesn't exploit the default-signature implementation, then the client code is perfectly portable, and even if the conditional API features are available they have no visible effect whatsoever. OTOH, if the client code wants to make use of the default implementation, it needs to be built with a compiler supporting the Generics language feature, and due to a) the library is guaranteed to provide the default-signature implementation as well as soon as the client is able to use it. The client-code is now deliberately non-portable (but on the other hand, the operational semantics are guaranteed to be consistent, as there's only one case to consider) Consequently, as both scenarios don't lead to problematic situations, I'd argue that there is no harm in allowing this kind of compile-time conditional APIs using the DefaultSignature language extension. ---- cheers, hvr [1]: "Proposal: Adding generics-based rnf-helper to `deepseq`" on libraries list http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17940 [2]: "[ANNOUNCE] hashable-generics" on haskell-cafe list http://comments.gmane.org/gmane.comp.lang.haskell.cafe/101323

7 12

Proposal: Add isLeft/isRight to Data.Either
by Simon Hengel 14 Dec '12

14 Dec '12

Hi, I propose to add isLeft/isRight to Data.Either, with the obvious definitions: isLeft :: Either a b -> Bool isLeft (Left _) = True isLeft (Right _) = False isRight :: Either a b -> Bool isRight (Left _) = False isRight (Right _) = True There has been a discussion on that before [1]. While I agree that fromLeft/fromRight are moot, I don't see issues with isLeft/isRight. Personally I care mostly about isLeft, but for orthogonality I propose to add both isLeft and isRight. Here is a (possibly incomplete) list of packages that come with their own definition of isLeft: snap-core, multifocal, PriorityChansConverger, tamarin-prover-utils, Agda, PCLT, cmdtheline, scyther-proof, xmlhtml, hspec-expectations, Glob, language-glsl, Craft3e, hledger-lib, narc, nemesis, type-settheory, PCLT-DB, RJson, bio, errors, rss2irc, heist Discussion period: 2 Weeks Cheers, Simon [1] http://www.haskell.org/pipermail/libraries/2006-October/006098.html

18 35

digamma function
by Ben Gamari 14 Dec '12

14 Dec '12

My digamma package[1] implements an approximation to the digamma function (due to Tom Minka). Considering that the math-functions package already has a gamma implementation, it seems it would be natural to merge digamma into this package. Alternatively (or additionally), James Cook's gamma package also has a variety of gamma implementations and is also a candidate for merging digamma into. I don't mind maintaining digamma, but it might be easier for others if there were a single package providing all of these functions. Do others have an opinion on this? Are either (or both) of you interested in picking up a digamma implementation? Cheers, - Ben [1] http://hackage.haskell.org/package/digamma

3 2

The PVP ought to mention dependency bounds (Was: Growing Haskell Platform)
by Johan Tibell 11 Dec '12

11 Dec '12

On Thu, Dec 6, 2012 at 11:52 PM, Michael Snoyman <michael(a)snoyman.com> wrote: > I thought the natural response to this would be to put a lower bound on > text. After all, following the PVP, there should be no problem with updating > a minor version number. However, when I did so, many users of the Haskell > Platform were no longer able to compile due to conflicting dependencies. The > result: I had to put in some dirty conditional compilation tricks in > persistent to avoid inlining `pack` when using older versions of text. I've meant to write about this but haven't yet found time to do so. Assuming that the goal of the PVP is to make sure that a packages that previously compiled continues to compile, dependencies must be taken into account when computing package version number bumps. For example, given these packages: A-1.0 B-1.0 depends on A-1.0.0.* C-1.0 depends on A-1.0.0.* and B-1.0.0.* Now assume that A-2.0 is released and B starts depending on the new version of A (without changing its own API). He now have this situation: A-1.0 A-2.0 B-1.?.?.? depends on A-2.0.0.* C-1.0 depends on A-1.0.0.* and B-1.0.0.* If B only bumps its patch-level version (i.e. to B-1.0.0.1), C no longer compiles (due to a version constraint failure) with B-1.0.0.1 even though C's dependency on B (i.e. B-1.0.0.*) suggests that it would. If B updates it's lower bound on a dependency it must bump its own major version number. We can summarize this under the slogan "versions are APIs"; the versions you depend on are part of your API. Aside: Even if cabal install would backtrack and *not* use the new version of B (i.e. B-1.0.0.1) and thus be able to compile C-1.0 using the old version of B things would still be bad as C's dependency constraints would be a lie. I think the PVP policy must be changed to require that increasing lower bounds on dependencies requires an increase in the major version number. -- Johan

8 15

whenJust / forM_ (was Re: Proposal: Add isLeft/isRight to Data.Either)
by Conrad Parker 11 Dec '12

11 Dec '12

On 8 December 2012 02:38, Erik Hesselink <hesselink(a)gmail.com> wrote: > On Friday, December 7, 2012, Thomas Schilling wrote: >> >> On 7 December 2012 09:25, Erik Hesselink <hesselink(a)gmail.com> wrote: >> > There is no need to define whenJust, since it is just a specialization >> > of forM_ from Data.Foldable. >> >> I don't know if that's such a good argument. I prefer my code >> readable -- too much abstraction can have a seriously bad effect on >> that. As a simple rule, if the user has to do type inference in their >> head, readability suffers. >> >> In this case, "forM_" implies we're iterating over something container >> like, "whenJust" means "I want to do something if this thing yielded a >> result". It depends on the context whether a "Maybe" is behaving more >> container-like or is indicating the presence of a result where there >> may not have been one. > > > I don't have this problem, but I guess that's just personal. But in general > I'm not in favor of adding specialized versions of generalized functions. indeed, and likewise we should get rid of Control.Monad.forM_ :: Monad m => [a] -> (a -> m b) -> m () which is just the same specialization to lists (and likely the reason that forM_ doesn't come to mind for other container types, as much as I generally like Data.Foldable). btw: $ git grep whenJust|wc -l 40 Conrad.

2 2

Re: portable encoding/decoding without going via a handle
by Ganesh Sittampalam 10 Dec '12

10 Dec '12

Hi Judah, On 25/11/2012 17:19, Judah Jacobson wrote: > I think some way to use BufferCodecs without going through the > filesystem would be very useful. One other approach would be > Bytestring-backed Handles; there was talk of them in the past, but I > don't know of any actual packages for it yet. That might be a simpler > approach than manipulating BufferCodecs directly, since you could just > use the functions from Data.Text.IO <http://Data.Text.IO> and all of the > buffering and error recovery would get taken care of automatically. > > This 2009 email from Simon Marlow references bytestring-backed handles > and has a code sample for memory-mapped files that might be helpful: > http://www.haskell.org/pipermail/glasgow-haskell-users/2009-December/018124… > He also mentions bytestring-backed Handles in this talk: > http://community.haskell.org/~simonmar/GHC-IO.pdf > That code's probably bitrotted a little, but seems like a good place to > start. Thanks for the pointers! Do you have any thoughts on what the API for creating a bytestring-backed handle should be? I'm particularly thinking of the case where we are writing to the bytestring - the type could be something like makeWritableByteStringHandle :: IO (Handle, ByteString) but then would we end up with a ByteString value that could be being mutated in parallel with being used. It might be nicer to have it in two phases, e.g. makeWritableByteStringHandle :: IO Handle finishByteStringHandle :: Handle -> IO ByteString but since Handle is a single type rather than a type class, that's not imlpementable. Perhaps: makeWritableByteStringHandle :: IO (Handle, IO ByteString) where the embedded IO action is only valid after the Handle has been hClose'd? Cheers, Ganesh

2 2