Marcin 'Qrczak' Kowalczyk wrote:
> stToIO looks better for me. What about declaring that lowercasing
> the first letter of an abbreviation consisting of only capital
> letters is realized by lowercasing the whole word? [...]
OK, this makes sense and the rule is not much more complicated.
> > e.g. proposals for the names of non-monadic versions of updateBlah,
>
> Edison uses
> update :: Seq s => Int -> a -> s a -> s a
> adjust :: Seq s => (a -> a) -> Int -> s a -> s a
> for what my guidelines could give
> setElem :: Seq s => s a -> Int -> a -> s a
> updateElem :: Seq s => s a -> Int -> (a -> a) -> s a
>
> Not that I don't like partial application, but Edison's order is
> usually not used elsewhere, [...]
Please note that at least since the hslibs shipped with GHC 4.06,
the `update' prefix has been taken by actions (namely updateIORef,
which has accompanied by an updateSTRef lately). I'm a little bit
reluctant to propose it for a different usage now. Edison uses it
in neither way. :-( But we could use Edison's `adjust' for the
non-monadic case.
> Bits (using separate setBit and clearBit instead of setBit with
> Bool parameter, and complementBit instead of updateBit - but the
> latter is OK) [...]
Well, Bits is IMHO an example for a module which is completely
messed up: Totally inconsistent naming, too many methods, etc.
Perhaps I'm grumbling about this in a different mail. >:-)
> Maybe we should promote Edison's order, which is consistent with
> module List, but what about above libraries?
Aaaah, finally something which has nothing to do with names. :-)
I don't have a clear picture about common practice regarding argument
order. Any ideas for simple rules which cover most cases? Remember:
This is not a futile attempt to prescribe everyone how to do things.
But remembering the argument order for the tons of functions within
hslibs without peeking into the respective docs is currently not easy,
so an easy convention would be nice here.
Cheers,
Sven
