News aggregator

Dynamic loadable modules?

Haskell on Reddit - Sun, 03/15/2015 - 5:43pm

Is there an easy way to do dynamic loadable Haskell modules? For example I have the modules A, B, C and they all export something of type Something. Based on the arguments by which the application is invoked I'd like to do import a specified module.

The alternative is of course to create a datatype like:

data LoadModule = ModuleA Something | ModuleB Something | etc... type Modules = [LoadModule]

Where I would transform the given input in a datatype by which I could find the desired one via constructor pattern matching. However I'm going to have around 40+ such modules and there is a lot more boilerplate with this approach.

submitted by alt_account10
[link] [13 comments]
Categories: Incoming News

package ParsecToken

haskell-cafe - Sun, 03/15/2015 - 3:00pm
I am new to the community and learning Parsec, reading the tutorial "Parsec, a fast combinator Parse" by Daan Leijen. In the tutorial, the examples import the package called "ParsecToken" and I could not find this package any where (I found many variants like Text.Parsec.Token, Text.ParseCombinators.Parsec.Token etc.) So I was unable to execute those examples given there. Q1. How do I find the package name for "ParsecToken" so that I can do cabal import? Thanks. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Question: Type System and N-Dimensional Vectors

Haskell on Reddit - Sun, 03/15/2015 - 2:02pm

AFAIK, in haskell, the two main ways to encode Vectors( In the mathematical sense ) are n-dimensional Tuples (t,t) or Lists [t]. Lists, of course, do not carry size information as part of their type. Tuples do, but the size must be constant--hardcoded into the type. My question is, is there any way to statically check vectors of arbitrary size. For instance, could we define a function like zip, which statically checks that its arguments are the same length, but doesn't specify the length. something like myZip:: vec t n -> vec t n -> vec (t,t) n. where t is the type of data held in the vector and n is the length. Thanks.

submitted by swisskid22
[link] [13 comments]
Categories: Incoming News

Brent Yorgey: Anafunctors

Planet Haskell - Sun, 03/15/2015 - 1:55pm

This is part four in a series of posts on avoiding the axiom of choice (part one, part two, part three).

In my previous post, we considered the “Axiom of Protoequivalence”—that is, the statement that every fully faithful, essentially surjective functor (i.e. every protoequivalence) is an equivalance—and I claimed that in a traditional setting this is equivalent to the axiom of choice. However, intuitively it feels like AP “ought to” be true, whereas AC must be rejected in constructive logic.

One way around this is by generalizing functors to anafunctors, which were introduced by Makkai (1996). The original paper is difficult going, since it is full of tons of detail, poorly typeset, and can only be downloaded as seven separate postscript files. There is also quite a lot of legitimate depth to the paper, which requires significant categorical sophistication (more than I possess) to fully understand. However, the basic ideas are not too hard to grok, and that’s what I will present here.

It’s important to note at the outset that anafunctors are much more than just a technical device enabling the Axiom of Protoequivalence. More generally, if everything in category theory is supposed to be done “up to isomorphism”, it is a bit suspect that functors have to be defined for objects on the nose. Anafunctors can be seen as a generalization of functors, where each object in the source category is sent not just to a single object, but to an entire isomorphism class of objects, without privileging any particular object in the class. In other words, anafunctors are functors whose “values are specified only up to unique isomorphism”.

Such functors represent a many-to-many relationship between objects of and objects of . Normal functors, as with any function, may of course map multiple objects of to the same object in . The novel aspect is the ability to have a single object of correspond to multiple objects of . The key idea is to add a class of “specifications” which mediate the relationship between objects in the source and target categories, in exactly the same way that a “junction table” must be added to support a many-to-many relationship in a database schema, as illustrated below:

On the left is a many-to-many relation between a set of shapes and a set of numbers. On the right, this relation has been mediated by a “junction table” containing a set of “specifications”—in this case, each specification is simply a pair of a shape and a number—together with two mappings (one-to-many relations) from the specifications to both of the original sets, such that a specification maps to a shape and number if and only if and were originally related.

In particular, an anafunctor is defined as follows.

  • There is a class of specifications.
  • There are two functions mapping specifications to objects of and .

, , and together define a many-to-many relationship between objects of and objects of . is called a specified value of at if there is some specification such that and , in which case we write . Moreover, is a value of at (not necessarily a specified one) if there is some for which .

The idea now is to impose additional conditions which ensure that “acts like” a regular functor .

  • Functors are defined on all objects; so we require each object of to have at least one specification which corresponds to it—that is, must be surjective.
  • Functors transport morphisms as well as objects. For each (the middle of the below diagram) and each in (the left-hand side below), there must be a morphism in (the right-hand side):

  • Functors preserve identities: for each we should have .
  • Finally, functors preserve composition: for all (in the middle below), , and (the left side below), it must be the case that :

Our initial intuition was that an anafunctor should map objects of to isomorphism classes of objects in . This may not be immediately apparent from the definition, but is in fact the case. In particular, the identity morphism maps to isomorphisms between specified values of ; that is, under the action of an anafunctor, an object together with its identity morphism “blow up” into an isomorphism class (aka a clique). To see this, let be two different specifications corresponding to , that is, . Then by preservation of composition and identities, we have , so and constitute an isomorphism between and .

There is an alternative, equivalent definition of anafunctors, which is somewhat less intuitive but usually more convenient to work with: an anafunctor is a category of specifications together with a span of functors where is fully faithful and (strictly) surjective on objects.

Note that in this definition, must be strictly (as opposed to essentially) surjective on objects, that is, for every there is some such that , rather than only requiring . Given this strict surjectivity on objects, it is equivalent to require to be full, as in the definition above, or to be (strictly) surjective on the class of all morphisms.

We are punning on notation a bit here: in the original definition of anafunctor, is a set and and are functions on objects, whereas in this more abstract definition is a category and and are functors. Of course, the two are closely related: given a span of functors , we may simply take the objects of as the class of specifications , and the actions of the functors and on objects as the functions from specifications to objects of and . Conversely, given a class of specifications and functions and , we may construct the category with and with morphisms in acting as morphisms in . From to , we construct the functor given by on objects and the identity on morphisms, and the other functor maps in to in .

Every functor can be trivially turned into an anafunctor . Anafunctors also compose. Given compatible anafunctors and , consider the action of their composite on objects: each object of may map to multiple objects of , via objects of . Each such mapping corresponds to a zig-zag path . In order to specify such a path it suffices to give the pair , which determines , , and . Note, however, that not every pair in corresponds to a valid path, but only those which agree on the middle object . Thus, we may take as the set of specifications for the composite , with and . On morphisms, . It is not hard to check that this satisfies the anafunctor laws.

If you know what a pullback is, note that the same thing can also be defined at a higher level in terms of spans. , the category of all (small) categories, is complete, and in particular has pullbacks, so we may construct a new anafunctor from to by taking a pullback of and and then composing appropriately.

One can go on to define ananatural transformations between anafunctors, and show that together these constitute a -category which is analogous to the usual -category of (small) categories, functors, and natural transformations; in particular, there is a fully faithful embedding of into , which moreover is an equivalence if AC holds.

To work in category theory based on set theory and classical logic, while avoiding AC, one is therefore justified in “mixing and matching” functors and anafunctors as convenient, but discussing them all as if they were regular functors (except when defining a particular anafunctor). Such usage can be formalized by turning everything into an anafunctor, and translating functor operations and properties into corresponding operations and properties of anafunctors.

However, as I will argue in some future posts, there is a better solution, which is to throw out set theory as a foundation of category theory and start over with homotopy type theory. In that case, thanks to a generalized notion of equality, regular functors act like anafunctors, and in particular AP holds.


Makkai, Michael. 1996. “Avoiding the Axiom of Choice in General Category Theory.” Journal of Pure and Applied Algebra 108 (2). Elsevier: 109–73.

Categories: Offsite Blogs

Generalizing map?

libraries list - Fri, 03/13/2015 - 10:32am
A dozen of functions like concat, foldr, mapM, have been generalized through BBP. Then, why do we leave `map` just for lists? Obviously `map` can be generalized, so map :: Functor f => (a -> b) -> f a -> f b map = fmap The current definition of `map` looks too special to be a special case of mapM (map f = runIdentity . mapM (Identity . f)). _______________________________________________ Libraries mailing list Libraries< at >
Categories: Offsite Discussion

Proposal: Export cycleN from Data.Sequence

libraries list - Wed, 03/11/2015 - 4:14pm
Yesterday I rewrote `*>` for Data.Sequence (again), using an internal function cycleN :: Int -> Seq a -> Seq a The name of the function is based on that of Data.Sequence.iterateN. cycleN takes a sequence and cycles it as many times as requested: cycleN 0 $ fromList [1,2] = [] cycleN 5 $ fromList [1,2] = [1,2,1,2,1,2,1,2,1,2] The function is written to maximize sharing in the result sequence and to minimize construction time. Specifically, cycleN n xs should take something like O(|xs| + log n) space (of which all but O(log |xs| + log n) is shared with the structure of xs) and O(log |xs| + log n) time. With current (on GitHub) Data.Sequence exports, the only way to get this functionality with these time and space bounds is to combine replicate with *> : cycleN n xs = replicate n () *> xs This strikes me as a bit unpleasant. David
Categories: Offsite Discussion

-staticlib flag for building standalone static libraries producing very large libraries

glasgow-user - Sat, 03/07/2015 - 1:18pm
Hi all, Can anyone explain the following problem I'm having? I'm currently writing a game in Haskell. When I produce a plain old executable (for local testing) it's about 23M. However, when I create a static lib using the -staticlib flag it is 54M. Why the discrepancy? Sean _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >
Categories: Offsite Discussion

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!


Categories: Incoming News