Re: [Caml-list] indent 2

[Markus Mottl <markus@mail4.ai.univie.ac.at>]

On Sun, 22 Jul 2001, Brian Rogoff wrote:
> A little extra section on programming with functors and the interaction
> with the file system would be helpful. I've read the manual and the 
> libraries, and there is not really a consistency of style there. For
> instance module types in the manual are UPPER_CASE, but MixedCaseWithSuffix 
> in the libraries. In another document the style used "Sig" as a suffix to 
> MixedCaseSuffix as opposed to Type in the libraries. Is there a preferred
> style yet? I've been playing with some heavily functorized libraries
> ported over from SML and since I'd like to make them Caml style I'd like
> examples of the desired naming styles. 

I don't know whether this is "a" standard style, but I have at least
seen it often and also use it consistently: module types are written in
capital letters where different words are separated by an underscore,
e.g.: "PARTIAL_ORDER".

Module implementations are written without underscores and with small
letters, but the first char of each subword is capitalized, e.g:
"PartialOrder".

> There was also some discussion on the duplication of module information in 
> the .mli and .ml files on the list which is a fine addition to either the
> FAQ or style guide. 

I didn't have the impression so far that any kind of "standard"
concerning the use of modules has appeared. Especially what concerns
functorized code, people use different approaches. See, for example,
the standard library (Set, Map) that puts both the result signatures of
functors and the functor signatures into the .mli file associated with the
implementation and therefore by necessity also into the implementation
files. I am not sure what the advantages are besides having to maintain
two files only. To me this looks like bad practice, because then I really
have to update two files if the signature changes (e.g. is extended),
which is not the case in approaches that use more than two files.

Furthermore, I think it is very cumbersome that implementations always
get opaque type. It might be a good idea to develop a scheme that allows
us to easily exploit concrete representations to e.g. extend them with
additional functionality that cannot be replicated efficiently (or at
all) with the abstract type alone. I'll describe an approach that I have
recently come across in another mail...

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr