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
ambiguity.
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,
Wolfgang
More information about the Libraries
mailing list