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 * 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

On Fri, 31 Oct 2008, Sean Leather wrote:

...

...

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.

I believe this is a Duncan-esque form of agreement with your recommendation.

I also agree with you. See, for example, EMGM's use of generic versions of Prelude functions.

What is EMGM?

On Fri, 2008-10-31 at 16:17 +0100, Sean Leather wrote:

> 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.

I believe this is a Duncan-esque form of agreement with your recommendation.

Indeed :-) Sorry for the ambiguity. I kind of accept some of the fooM functions since they've been there for so long, but new ones make me itch to fix them. Duncan

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.