- Libraries - Haskell.org

ANN: sandi 0.1.1 - a data encoding/decoding library
by Magnus Therning 29 Dec '12

29 Dec '12

The other day I released version 0.1.1 of sandi, a data encoding/decoding library supporting the following encodings: base16, base32, base32hex, base64, base64url, base85, quoted-printable, uuencode, xxencode, yEnc I believe it's reasonably fast, but I still have to look more closely at criterion to get some hard numbers confirming that :) More details can be found at http://hackage.haskell.org/package/sandi /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay

1 0

Re: Maximum and Minimum monoids
by Gabriel Gonzalez 29 Dec '12

29 Dec '12

I'm still not convinced by the Bounded instance for Maybe, which seems like a hack. I would prefer to just use the Monoid instance for "Maybe (Max a)" and just fmap "getMaximum" over the result rather than pretend that Maybe is Bounded when it's not. Moreover, the entire Bounded constraint seems wrong in principle. There is no intuitive reason why some type should be bounded to be able to take a maximum of a set of elements. The Ord constraint should be sufficient to define a maximum. I also don't think it is a good idea to have direct Monoid instances for Max and Min, because they behave weirdly on empty lists. Do you really think that "minimum [] :: Int" should be defined? I still believe that the correct answer for "minimum []" should be Nothing or a similar type with a distinguished infinity like those that Roman proposed.``

3 3

Re: Maximum and Minimum monoids
by Gabriel Gonzalez 28 Dec '12

28 Dec '12

I am definitely in favor of adding "semigroups" to the platform if drops the containers dependency. Optionally, we could then fix the Monoid instance for Maybe so that it has a proper semigroup context and we wouldn't have to use the Option type. I would be happy with that solution. However, if we do that then rename the types to "Max" and "Min" instead of "Maximum and "Minimum", since "Maybe (Max a)" is long enough as it is.

4 9

Re: Maximum and Minimum monoids
by John Lato 28 Dec '12

28 Dec '12

+1 for something like this. I've written these at least once, and encountered them on a few more occasions. I would prefer specific types as Roman suggests, I think. I prefer to match on Plus/MinusInfinity rather than going via Maybe. John L. > From: Roman Cheplyaka <roma(a)ro-che.info> > Subject: Re: Maximum and Minimum monoids To: Gabriel Gonzalez <gabriel439(a)gmail.com> > Cc: libraries(a)haskell.org > Message-ID: <20121227202510.GA24842@sniper> > Content-Type: text/plain; charset=us-ascii > > Wouldn't it be better to have a real algebraic type instead of wrapping > Maybe? > > Something like > > data Maximum a = MinusInfinity | Maximum a > data Minimum a = PlusInfinity | Minimum a > > Maximum x is more concise than Maximum (Just x), and MinusInfinity is > more descriptive than Maximum Nothing. getMaximum/getMinimum functions > can still return Maybes. > > Anyway, I'm +1 to having something along these lines. > > Roman >

1 0

What is the best usage of haskell in terms of build-in capabilities or external libraries?
by Peng Yu 19 Dec '12

19 Dec '12

Hi, When a language is selected for a project, a practical matter is what the language provides. For example, if I need to use regex a lot, I probably want to use perl rather than other languages, because perl is the best in terms of regex and have much influence on other languages that have support on regex. If I need to do a lot of statistics, I'd better use R, because there are already a lot of statical packages implemented in R. And if there is a statistical method, it is most likely to implemented in R first. If I want to implement matrix numerical algorithm, I'd better use Fortran. After reading some wiki pages of haskell, it is not clear to what area haskell is really good for. One strong point seems to be a testbed for trying new languages. But this seems to be the case for other functional languages as well. Is there an application area in which haskell is much stronger than other different languages? -- Regards, Peng

3 2

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