darcs patch: Added list operations for arrows

Evan Laforge qdunkan at gmail.com
Wed Nov 5 18:08:58 EST 2008

> I would definitely not like to have to use
> Monoid.append
> Arrow.filter
> Monad.filter
> Monad.map
> ...just on grounds of verbosity. Too many characters = ugly code.

I think that depends a lot on individual taste and what you're used
to.  The above looks fine to me (and I use that style exclusively in
my own code, except infix operators).  It would also probably look
normal to any python programmer.  Even though python supports both
qualified and unqualified, the default is qualified, and it's what
people are used to.

> But the alternative - to use short module aliases - does not scale well. I
> need to add appropriately qualified import statements to every single module
> in my project. We can't reexport qualifications.

Well, you do have to explicitly import every module you use, but
that's true of unqualified import too, so I'm not sure what the not
scaling part here is.  Do you object to the idea that you have to give
each module a name by hand and nothing stops you from being
inconsistent about the names you give one module?  I use the complete
module name with a few exceptions, but even with that I sometimes have
to put a bit of redundancy in module names to not conflict with a
similar name in a neighbor package.

Re-exporting qualified names doesn't seem like it would help... you'd
still get name clashes unless it was done python style like
Mod1.Mod2.f, but that's even more verbose.  However, in a module that
pulls together a lot of other modules using just one or two functions
from each (which is the one likely to do lots of intra package imports
and get clashes), I like the extra verbosity.  The wider the scope of
a name the longer it can be.  It seems to scale just fine for me, and
I have modules that import 40 or so other modules... in fact the more
you import the more I appreciate qualified names.

More information about the Libraries mailing list