Re: [Ocaml-lib-devel] Ocaml indent?

[Brian H. <bri...@ql...>]

On Tue, 25 Feb 2003, Maxence Guesdon wrote:

> What a pity when the type of a function (for example the order of
> arguments) is *almost* what we need and we have to create a dummy
> function, for example to change the order of the arguments...

How much of a problem is this?  I mean, to do:
let foo x y = bar y x ;;
strikes me as being seriously trivial.

A bigger problem for me is to make the arguments in a standard order.  One 
thing that *always* annoys me in C is:
    fprintf(stream, "string");
    fputs("string", stream);

I'd much perfer to have a standard order for arguments, to make them 
easier to remember.  For example, in data-structure oriented APIs, the 
data structure to act upon/use should always be the first argument.  Etc.
Having to look up the order of arguments every time you use the function 
encourages programmers to not use the function.

Speaking of which- I came upon an issue writting my psqueue library.  For 
data structures that have uniqueness constraints (hashes, trees, etc) what 
happens when you add an element that is already there, or modify/remove an 
element that isn't there?  There are two sets of ideology on this that I 
know of:

- The "loose" philosophy- quietly do "the right thing".  Adding an element
(or key)  that already exists simply replaces the previous element(key).  
Removing or modifying a key that doesn't exist does nothing.  The belief 
here is that what the programmer meant, or what is likely to do the least 
damage, is obvious, and you shouldn't blow up the entire program when 
there is an obvious way to continue.

- The "strict" philosophy- throw an exception on these cases.  The 
programmer asked to do something "nonsensical" and should fix his program, 
rather than take the chance that the library will guess wrong what the 
correct behavior is.  And the sooner the library helps the programmer 
catch his mistake, the easier it is to fix.

My "solution" is to provide both and let the programmer pick which he
wants.  IIRC, I used add/remove for the loose versions, and insert/delete
for the strict versions.


> 
> BTW, what about labels ? with or without ? I vote for only optional labels,
> except for functions with plenty of arguments of the same type.

My general philosophy on labels is that they should only be used when 
there is a real good reason to use them.  What a 'real good reason' is I'm 
still working on.

Brian