[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Sat, 24 Jun 2000 14:34:37 +0200, Sven Panne <[EMAIL PROTECTED]>
>pisze:
>
> > 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).
I just scanned through some of my code and it seems that I
relatively consistently place the old version as the first
argument in my libraries. Indeed one of the few places
where I used the last argument is my finite map
implementation and I am always messing up the arguments of
these functions when I use them.
In fact, I think, one reason that makes it difficult to find
a single rule here is because we essentially two different
classes of functions:
(1) Functions describing a generic traversal of a data
structure (like the well know list functions map, foldr,
etc).
(2) Functions modelling state updates (eg, entering elements
into a finite map etc).
In the first case, partial applications are often very
useful, which promotes the use of the last argument for the
traversed data structure. In contrast, state updates (ie,
functional state transformers) feel more natural when the
modified structure is the first argument. Reasons for this
are probably that this is the convention that we are used to
from imperative and oo languages, and furthermore, when
reading a program containing such functions, the most
important question is `which structure is modified', and then,
we check how the structure is modified exactly.
Manuel
