darcs patch: Added list operations for arrows

Wolfgang Jeltsch g9ks157k at acme.softbase.org
Fri Oct 31 10:45:17 EDT 2008

Am Freitag, 31. Oktober 2008 14:21 schrieben Sie:
> On Fri, 2008-10-31 at 13:26 +0100, Wolfgang Jeltsch wrote:
> > Am Donnerstag, 30. Oktober 2008 18:17 schrieb Peter Collingbourne:
> > > Hello,
> > >
> > > This patch adds two arrow combinators which I have found useful: mapA
> > > (equivalent of map) and filterA (equivalent of filter).
> > >
> > > Thu Oct 30 16:50:02 GMT 2008  Peter Collingbourne <pcc03 at doc.ic.ac.uk>
> > >   * Added list operations for arrows
> > >
> > > Thanks,
> >
> > Hello,
> >
> > wouldn’t it be better to stop using identifiers containing categorization
> > in form of single letters like filterA, mappend, etc.?  I’d say, we have
> > the module system for this: Monoid.append, Arrow.filter, etc.  Is someone
> > interested in cleaning up the library interfaces in this regard while
> > maintaining compatibility?
> Here here!
> 'A.filter' rather than 'filterA' (with a suitable qualified import).
> Duncan

Hmm, is this meant ironically or seriously?  Sorry, I just don’t know.

A.filter has the advantage over filterA that it has more structure: the module 
name expresses the general topic and the actual name denotes the concrete 
function.  In addition, you can drop the qualification if there is no 

Another point is that filterA uses just a single letter for “arrow”.  This 
concept quickly leads to ambiguities.  For example, in mappend, the “m” 
stands for “monoid” while in msum, it stands for “monad”.  Something like 
filterArrow would have the disadvantage that it is longer.  With qualified 
imports, the user of the library can decide whether to use a single letter 
(A.filter) or something more descriptive (Arrow.filter).

I think, this topic came up a while ago on some Haskell list already and there 
were several people arguing that employing the module system as I suggest was 
the better way.

Best wishes,

More information about the Libraries mailing list