is of course to limit all functions to one argument, and use CurryingSchonfinkelling
for the rest of the parameters. For some reason, however, this suggestion isn't a very popular one... ;) - JayOsako
I was just typing in this copy function:
template <class T> void CopyImageAndDisplay?(T *dstAcuObj, T *srcAcuObj)
and I realized that I reflexively put the destination argument first. I started wondering why I did that. Probably a habit formed by years of programming C/C++ and x86 assembly. I got curious and did a quick non representative scan through the MSDN library. I expected that something designed from the ground up (Java) would have some kind of convention but it doesn't seem like it. It's kind of hard to tell because OO tends to use Obj.Copy(src), which I can't do with my template function.
So, to satisfy my curiosity, can someone point me to a poll or some stats or, better yet, does someone have the definitive answer?
I suppose I would do it instead like this:
destImage = srcImage.copy();
destImage.display( dispCtx );
Or some variation of that. -- RobertDiFalco
Nope, but if I wanted to bluff, I might start with
dest = src;
If you really had to keep the 2-argument function, you could at least catch some common mistakes up-front with:
void CopyImageAndDisplay?(T *dstAcuObj, const T *srcAcuObj)
On the other hand, in assembly language and in machine code, the destination is (always ?) specified after the source (when they occur in different instructions):
src @ dest ! \ in the ForthLanguage
When different source and destination arguments occur in the same assembly language instruction, some assemblers put the source first, others put the destination first, which assembly language programmers find endlessly confusing when they start using a different processor. (I've heard some people talk about Intel order vs. Motorola order, from the traditional assemblers for x86 vs. 680x0 processors).
most assemblers for the 680x0 allow you to write
move.b 7, d0 ; move 7 into d0
most assemblers for the 80x86 allow you to write
mov al, 7 ; set al to 7
although the AT&T assembler for the 80x86 has the arguments swapped the other way around.
calls the 2 possible orderings "Intel style" vs. "AT&T style".
Using "x86 vs. 68k" in this sense, though, can be confused with another sense - x86 chips are LittleEndian while 68k chips are BigEndian.
Most command line programs (for UNIX, DOS, and Windows) are of the form "mv src dst", mainly because you might want to do "mv src1 src2 src3 dst/" instead.
Linguistically, the object that changes
(the destination object) is often the "primary actor" of the sentence, and thus it makes sense to put it first. Kind of akin to most languages putting the object first in imperative clauses, followed by adverbials. This kind of emphasis is demostrated by both
fprintf(stderr, "%s to your %s", swearwords[errno], argv);
When designing function or method signatures, I always prefer to put destinations before sources, mimicking assignment and following (I think) long years of tradition. (Examples: strcpy
in C, rplaca
in ancient Lisp, DAXPY
in the BLAS. Counterexample: copy
in the C++ standard library.) The first few assemblers I used followed the same convention, so I find the reverse uncomfortable; oddly enough the Unix mv
command doesn't bother me at all. I think assemblers should adopt syntax that makes the direction of assignment explicit: perhals "mov al <- 7" versus "mov 7 -> al", etc. I believe Intel's assembler for Itanium does something like this. -- GarethMcCaughan
Yes, I often wish for a slighly improved assembly language. Should we collect ideas on a wiki page -- is BetterAssembly? a good name ? ... -- DavidCary
PL360 (one of the WirthLanguages
) is a good example of a structured assembly language. See Wirth's technical report available here:
Whenever I'm writing code in ObjectiveCaml
, I try to put my destinations first... because OCaml allows partially-applied functions, which I can then pass to iterators more easily.
let foo src dest = ... in
List.iter (fun x -> foo x somecollection) somelist
let foo dest src = ... in
List.iter (foo somecollection) somelist
The expression (foo somecollection) returns a new function which takes one argument, which happens to be the source. It really doesn't change the semantics I suppose, and could be argued to be less clear (I don't think it is), but is nicer to write.
And now for something completely different: http://www.haskell.org/ghc/docs/edison/users004.html#toc10
Whenever a function takes multiple arguments, there is a choice as to the order of the arguments. I have tried to make these choices according to the following rules, in decreasing order of importance:
- Favor an order that is more useful for partial applications.
- Favor an order with significant mnemonic value.
- Functions that modify a collection should take the collection last.
- Consistency with similar operations.
- Personal taste.
perhaps related to WhyIsTheFirstArgSpecial