Sat, 24 Jun 2000 14:34:37 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
> 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.
I too prefer distinguishing similar operations that differ in
monadness, to avoid silly mistakes that may make some people feel
"stupid Haskell forces me to remember what is monadic and what is not,
what a silly distinction". But it's hard to do all the time anyway
(e.g. isX, setX), so some exceptions should not hurt much.
For updating we have: update, modify, adjust. I proposed modify for
the monadic case, because IMHO it sounds most imperatively and better
than update suggests that the old value is used. You changed it to
update. OK, I have not strong feelings for modify.
Monadic modify is used in MonadState. Monadic update is used in
{IO,ST}Ref. Pure adjust is used in Edison. Something like pure update
is produced by DrIFT. I have not found more in lib/std or hslibs.
> I don't have a clear picture about common practice regarding argument
> order. Any ideas for simple rules which cover most cases?
For functions that take an old version of something plus some modifiers
and return a new version, current practice is inconsistent.
Old version is the first argument:
(Array.//)
FiniteMap
Bits
PosixTTY
plusAddr
Old version is a middle argument:
Array.accum
Old version is the last argument:
Prelude.fmap
List
Array.ixmap
MonadState
Edison
PackedString
Maybe we should promote the last argument, while stating that for
historical reasons it is not always used...
Rationale for the last argument: partial application of course,
using layout where the old value is complex and modifiers are simple,
and applying many modifications at once (the last case works for the
first argument variant only when there is exactly one other argument,
so the function name can be put in backquotes).
------------------------------------------------------------------------
Some other rules.
When a function takes a state and returns a pair consisting of some
result and an updated state, the result should be first and the state
should be second. Seems to be consistently used (Random, MonadState).
When an Either result encodes a good result or an error, the error
should be Left and the good result should be Right. Rationale:
partially applied type is a good Functor and Monad. Seems to be
consistently used (MonadEither, Parsec).
------------------------------------------------------------------------
Edison's documentation contains various argument order rules.
------------------------------------------------------------------------
I am trying to make an unified system of classes that would catch
three Edison's families: sequences, collections and associations.
And maybe the fourth that does not fit into these and is missing:
arrays. It's hard and complex :-( Results are less ugly when
functional dependencies are used, but I still cannot keep the whole
functionality of current Edison.
The problem is that if element type is going to the context, then
it's impossible to have methods like current
intersectWith :: FiniteMapX m k => (a->b->c) -> m k a -> m k b -> m k c
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
