Re: [Caml-list] Dequeues (was Generation of streams is slow)

Re: [Caml-list] Dequeues (was Generation of streams is slow)

[Krishnaswami, Neel]

Chris Hecker [mailto:checker@d6.com] wrote:
> 
> Has anybody written a simple "circular linked list" 
> implementation in ocaml?  Basically, you'd want it to act 
> exactly like the built in lists, but appends and finding the 
> tail elemeent are O(1).

Markus Mottl has implemented the functional double-ended 
queue structures in Okasaki's _Purely Functional Data Structures_.
Look for it at:

http://www.ai.univie.ac.at/~markus/ocaml_sources/pure_fun-1.0-2/

> It doesn't seem possible to make this as convenient as the 
> built in list, since :: doesn't seem to be redefinable, and I 
> don't know how you'd make this work in pattern matching.  Is 
> there any work on making user defined abstract types work in 
> pattern matching?

IIRC, the ability to pattern-match on abtract types is called 
called "views". There are a number of proposals for adding
them to the ML family, but I'm not really competent to judge
between them. 

The usual argument for them is that there's a strong temptation 
to avoid proper data abstraction in ML because pattern-matching 
is so convenient, and the usual argument against them is that 
they make estimating the performance costs of pattern-matching 
impossible, since a match could be an arbitrarily expensive 
function call. Personally, I like views; here are some references
so you can judge for yourself:

http://www.cs.columbia.edu/~cdo/papers.html#ml98views
http://cm.bell-labs.com/cm/cs/who/wadler/papers/view/view.dvi
http://www.cs.orst.edu/~erwig/papers/abstracts.html#IFL96

In the meantime, a useful workaround in OCaml is to use folds
with keyword arguments. Eg, 

type regexp =
    Epsilon
  | Char of char
  | Kleene of regexp
  | Seq of regexp * regexp
  | Alt of regexp * regexp

let fold ~epsilon ~char ~kleene ~seq ~alt =
  let rec fold' = function
    | Epsilon -> epsilon
    | Char c -> char c
    | Kleene re -> kleene (fold' re)
    | Seq(a, b) -> seq (fold' a) (fold' b)
    | Alt(a, b) -> alt (fold' a) (fold' b)
  in fold'

And then instead of doing something like this: 

let rec fold_case = function
  | Epsilon -> Epsilon
  | Char c -> Alt(Char(Char.uppercase c), Char(Char.lowercase c))
  | Kleene re -> Kleene (fold_case re)
  | Seq(a, b) -> Seq(fold_case a, fold_case b)
  | Alt(a, b) -> Alt(fold_case a, fold_case b)

You can write the function like this:

let fold_case' =
  fold
    ~epsilon: Epsilon
    ~char: (fun c -> Alt(Char(Char.uppercase c), Char(Char.lowercase c)))
    ~kleene: (fun re -> re)
    ~seq: (fun a b -> Seq(a, b))
    ~alt: (fun a b -> Alt(a, b))

This is not /quite/ as readable as pattern matching, but IMO it's
pretty near it.

--
Neel Krishnaswami
neelk@cswcasa.com
-------------------
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

Re: [Caml-list] Dequeues (was Generation of streams is slow)

[Chris Hecker]

>The usual argument for them is that there's a strong temptation 
>to avoid proper data abstraction in ML because pattern-matching 
>is so convenient, and the usual argument against them is that 
>they make estimating the performance costs of pattern-matching 
>impossible, since a match could be an arbitrarily expensive 
>function call.

I've seen this "argument against" a number of times before on this list (like when people wanted constants in patterns), and I don't understand it.  What's the rationale for trying to protect the programmer from making slow code at the expense of useful and expressive features?

Chris

-------------------
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

[Caml-list] Views

[Chris Hecker]

> Personally, I like views; here are some references
>so you can judge for yourself:
>http://www.cs.columbia.edu/~cdo/papers.html#ml98views
>http://cm.bell-labs.com/cm/cs/who/wadler/papers/view/view.dvi
>http://www.cs.orst.edu/~erwig/papers/abstracts.html#IFL96

Those are excellent!  Exactly what I wanted and have wanted for a while when I realized that pattern matching didn't work on abstract types.  Is there any chance of getting something like this into ocaml?  What do the INRIA folks think about the idea?

Chris


-------------------
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

Re: [Caml-list] Dequeues (was Generation of streams is slow)

[Brian Rogoff]

On Fri, 20 Jul 2001, Krishnaswami, Neel wrote:
> Chris Hecker [mailto:checker@d6.com] wrote:
> > 
> > Has anybody written a simple "circular linked list" 
> > implementation in ocaml?  Basically, you'd want it to act 
> > exactly like the built in lists, but appends and finding the 
> > tail elemeent are O(1).

I appended a simple circular linked list module to this message. Not
tested, but it type checks ;-). It should be close enough, but be warned,
it's evil imperative code. 

> > It doesn't seem possible to make this as convenient as the 
> > built in list, since :: doesn't seem to be redefinable, and I 
> > don't know how you'd make this work in pattern matching.  Is 
> > there any work on making user defined abstract types work in 
> > pattern matching?

I don't think that pattern matching buys you much with the imperative
lists. 

> IIRC, the ability to pattern-match on abtract types is called 
> called "views". There are a number of proposals for adding
> them to the ML family, but I'm not really competent to judge
> between them. 

> function call. Personally, I like views; here are some references
> so you can judge for yourself:
> 
> http://www.cs.columbia.edu/~cdo/papers.html#ml98views
> http://cm.bell-labs.com/cm/cs/who/wadler/papers/view/view.dvi
> http://www.cs.orst.edu/~erwig/papers/abstracts.html#IFL96

As long as you're there at Martin Erwig's page see 

http://www.cs.orst.edu/~erwig/papers/abstracts.html#Haskell00

too. Much of that was influenced by his (very cool) functional graph
library. 

In addition to the "folds with keyword arguments" trick you show,
there was also a similar approach mentioned on c.l.functional of defining
an external type to match your abstract one, and that trick even works in
SML. I think with polymorphic variants that trick is even a little nicer.  

-- Brian

(* circlist.mli *)
type 'a t
val make : 'a -> 'a t
val peek_front   : 'a t -> 'a
val peek_back   : 'a t -> 'a
val push_front : 'a -> 'a t -> 'a t
val push_back : 'a -> 'a t -> 'a t 
val pop_front : 'a t -> 'a
val insert_front : 'a t -> 'a t -> unit
val insert_back : 'a t-> 'a t -> unit
val iter : ('a -> unit) -> 'a t -> unit
val map : ('a -> 'b) -> 'a t -> 'b t

(* circlist.ml *)
type 'a t = { data :'a; mutable next : 'a t }

let make v =
  let rec x = {data = v; next = x} in 
  x 

let peek_front l  = l.next.data
let peek_back l  = l.data

let push_front e l  = 
  let new_first = {data = e; next = l.next} in 
  (l.next <- new_first; l)

let push_back e l  = 
  let new_last = {data = e; next = l.next} in 
  (l.next <- new_last; new_last)

let pop_front l = 
  if l == l.next then 
    failwith "Circlist.pop_front"
  else
    let result = l.next.data in 
    (l.next <- l.next.next; result)

(* insert elems into the front of l, returning modified l *)
let insert_front elems l =
  let front = elems.next in 
  (elems.next <- l.next; 
   l.next <- front;
   l)

(* insert elems at the back of l, returning modified 
   elems (which is last) 
*)
let insert_back elems l =
  let front = l.next in 
  (l.next <- elems.next;
   elems.next <- front; 
   elems)

let iter f l = 
  let rec loop cl = 
    if cl == l then f cl.data
    else (f cl.data; loop cl.next) in 
  loop l.next

let map f l = 
  let r = ref [] in 
  (iter (fun v -> r := (f v)::!r) l;
   let result = make (List.hd !r) in 
   List.iter (fun v -> ignore (push_front v result)) (List.tl !r);
   result)


-------------------
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

[Caml-list] indent 2

[Alexander V. Voinov]

Hi All,

Is the indentation with the step 2 a _must_ for those who program in
OCaml? I got used 4, and already set all the necessary variables for
caml-mode, so that I get:

let count_range bt lwb upb =
    let bti = (IVB.from_to bt lwb upb) in
    let rec count1 bti n =
	if IVB.ok bti then begin
	    match IVB.next bti with
		Some (k, v, b) ->
		    (printf "in count1 %d %d %b\n" k v b); flush stdout;
		    let n' = if b then n + 1 else n in
		    count1 bti n'
	      |	None -> raise (Failure "this cannot happen")
	end
	else
	    n
    in
    count1 bti 0

Is this horrible/terrible/tolerable/appropriate?

Alexander
-------------------
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

Re: [Caml-list] indent 2

[Pierre Weis]

> Hi All,
> 
> Is the indentation with the step 2 a _must_ for those who program in
> OCaml? I got used 4, and already set all the necessary variables for
> caml-mode, so that I get:
> 
> let count_range bt lwb upb =
>     let bti = (IVB.from_to bt lwb upb) in
>     let rec count1 bti n =
> 	if IVB.ok bti then begin
> 	    match IVB.next bti with
> 		Some (k, v, b) ->
> 		    (printf "in count1 %d %d %b\n" k v b); flush stdout;
> 		    let n' = if b then n + 1 else n in
> 		    count1 bti n'
> 	      |	None -> raise (Failure "this cannot happen")
> 	end
> 	else
> 	    n
>     in
>     count1 bti 0
> 
> Is this horrible/terrible/tolerable/appropriate?
> 
> Alexander
> -------------------
> 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

Instead of answering by a two lines long comment and my version of
the best version of your program, I prefer to redirect you to a more
appropriate and documented source concerning Caml programming styles.

This is a good occasion for me to announce a major rewritting of the
Caml programming guide lines where this question is discussed in the
large among a lot of others concerning style, including where to break
lines in Caml programs, where and why use (or avoid) parens, etc.

          http://pauillac.inria.fr/caml/FAQ/pgl-eng.html
          http://pauillac.inria.fr/caml/FAQ/pgl-fra.html

Each programming problem is normally carefully discussed with
arguments (and counter-arguments, and sometimes
counter-counter-arguments) gathered from observation of a lot of Caml
programs including the Caml compilers source code, and from statements
and advices from some of the best Caml programmers in the world, not
mentionning one of the best source of counter-counter-meta-arguments I
know about Caml programs indentation and syntax problems: the sudden
and not always so kind flamewares that appear, while quietly sitting
for lunch in the INRIA's cafeteria !

However, if there is something new to add to these guidelines, feel
free to drop me a not: I would be glad to translate it in french or
english or even incorporate it as is, if you provide a
translation. Don't hesitate to signal an error either, since this is
the worse situation to face for a guideline writter to incorporate a
bug in the suggested programming style!

Thanks in advance for your help,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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

Re: [Caml-list] indent 2

[Markus Mottl]

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

Re: [Caml-list] indent 2

[Luc Maranget]

Ah, the good old days,...

> 
> On Sun, 22 Jul 2001, Pierre Weis wrote:
> > > On Sat, 21 Jul 2001, Alexander V. Voinov wrote:
> > > > Oh, if it were that simple. The pressure of the society may be much
> > > > stronger than the pressure of an external authority, which contrasts
> > > > itself to the society. Because the former penetrates deeper into one's
> > > > mentality. (Sorry for offtopic)
> > > 
> > > That's too deep for me, I'm just an American. 
  You should not be ashamed of it, after all you are a US Citizen
(or Resident...).

  No hay nigun problema, de toda manera Usted es Estadounidense.



> > 
> > I can't resist to cite this slogan that I learnt long time ago from
> > the chinese communists (I really do not remember if it were about Caml
> > programming guidelines or not):
> 
> >  Always follow the party's line,
> >  but don't be afraid to swim against the main stream.
> 
> Is four spaces not following the party's line, or is it just swimmming
> against the main stream? 
  No trouble, dialectics tells us that the party's line may or may not
coincide with the main stream. As a wanna be party ideologist I would
say that  four spaces is swimming against the main stream.



> > [...]
> > > It seems that the Caml community mostly indents by two spaces, so if 
> > > you'd like to be a good neighbor you should do so as well. No one will 
> > > shun you if you refuse and use four spaces, and your code will still 
> > > be readable. Well, OK, I'll shun you, but probably noone else :-).
> > 
> > I will shun you also, but probably nobody else.
> 
> Hey, we may be onto something with this shunning thing...
> 
> > Oh yes, now I remember,
> > for indentation the chinese slogan was:
> > 
> >  Consistenly use one or two extra spaces when indenting,
> >  but fill free to indent as you like it.
  That's enligtning. Great example of the party's leadership
and wisdom. Long life to president Weis.



  More seriously, two spaces indentation is harmony. But the weather
^^ (one, two)
in Rocquencourt is two smooth and we lack manpower, so that organizing a
camp here for dissidents is not possible. Sorry, you are on your own.


--Luc

-------------------
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

Re: [Caml-list] indent 2

[Brian Rogoff]

On Sun, 22 Jul 2001, Pierre Weis wrote:
> > On Sat, 21 Jul 2001, Alexander V. Voinov wrote:
> > > Oh, if it were that simple. The pressure of the society may be much
> > > stronger than the pressure of an external authority, which contrasts
> > > itself to the society. Because the former penetrates deeper into one's
> > > mentality. (Sorry for offtopic)
> > 
> > That's too deep for me, I'm just an American. 
> 
> I can't resist to cite this slogan that I learnt long time ago from
> the chinese communists (I really do not remember if it were about Caml
> programming guidelines or not):

>  Always follow the party's line,
>  but don't be afraid to swim against the main stream.

Is four spaces not following the party's line, or is it just swimmming
against the main stream? 

> [...]
> > It seems that the Caml community mostly indents by two spaces, so if 
> > you'd like to be a good neighbor you should do so as well. No one will 
> > shun you if you refuse and use four spaces, and your code will still 
> > be readable. Well, OK, I'll shun you, but probably noone else :-).
> 
> I will shun you also, but probably nobody else.

Hey, we may be onto something with this shunning thing...

> Oh yes, now I remember,
> for indentation the chinese slogan was:
> 
>  Consistenly use one or two extra spaces when indenting,
>  but fill free to indent as you like it.
> 
> (Sorry for not being so serious about that (in fact) important subject.)
> 
> More seriously: Caml is a language of expressions (not blocks of
> instructions), and expressions tend to nest rather deeply. Hence it is
> not uncommon to have indentation level growing up to 5 in a regular
> program (in some bad cases it could go up to 10). 

I've never had 10, but definitely nesting 4 or 5 deep is common and ugly
with four space indenting IMO. 

> Personnaly, I use one
> space with some exceptions for 2 spaces indentation (which is
> inconsistent, I know it!) 

Well, you know what Emerson said about foolish consistencies. Then again, 
I do have a little mind!

> > PS: It would be useful to have the programming guidelines extended to
> >     cover programming with classes and modules. 
> 
> I added some paragraph on modules. May be you can tell me what topics
> I have to add or extend about modules ? 

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. 
 
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'm not sure why you don't mention local modules in the section on opening
modules since I think that in many cases a local open is better than a 
file/top-level-unit wide open. Is using let module this way questionable 
style?

> For classes, I'm a bit more puzzled and I need help from people that
> use classes more than I do, and that already know what are the problems
> to avoid and the styles to recommend.

I'm still accumulating experience here. I only use classes in a few
places.

-- Brian


-------------------
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

Re: [Caml-list] indent 2

[Jeremy Fincher]

> Its wise to invest some time reading the compiler sources. I wish I had
> done so earlier.

What should a programmer be looking for when reading the compiler sources?

Jeremy
-------------------
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

Re: [Caml-list] indent 2

[Markus Mottl]

On Sun, 22 Jul 2001, Pierre Weis wrote:
> Personnaly, I use one space with some exceptions for 2 spaces
> indentation (which is inconsistent, I know it!) for reasons that are
> explained in the Caml programming guidelines. (In short, I write
> 2 spaces to align the |'s in the pattern matchings of function
> definitions:

Always eager to improve the syntactic beauty of my sources, I wondered
how this indentation style looks like so I peeked at the implementation
of the Format-module, which seems to be written by you.

Indeed, this style is obviously very coherent: one can find anything
from 1, 2 to 4 spaces of indentation consistently applied throughout
the whole file, e.g.:

  let add_queue x q =
   let c = Cons {head = x; tail = Nil} in
   ...

  let pp_print_as state n s =
    if state.pp_curr_depth < state.pp_max_boxes
    ...

  let pp_print_newline state () =
      pp_flush_queue state true; state.pp_flush_function ()
      ...

The rules can be easily inferred: one space if the function body starts
with a "let", two if it starts with "if" and four in any other case.

Is it this kind of consistency you mean in the Programming Guidelines? :-)

Best regards,
Markus Mottl

  P.S.: Sorry for my sarcasm! As usual I couldn't resist... ;)

-- 
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

Re: [Caml-list] indent 2

[Pierre Weis]

> No idea why I was specifically addressed for this, but since you ask...
> 
> On Sat, 21 Jul 2001, Alexander V. Voinov wrote:
> > Hi Damien,
> > 
> > Damien Doligez wrote:
> > > 
> > > >From: "Alexander V. Voinov" <avv@quasar.ipa.nw.ru>
> > > 
> > > >Is the indentation with the step 2 a _must_ for those who program in
> > > >OCaml? I got used 4, and already set all the necessary variables for
> > > 
> > > Hey, the Soviet Union doesn't exist any more.  Welcome to the free
> > > world, comrade.
> > 
> > Oh, if it were that simple. The pressure of the society may be much
> > stronger than the pressure of an external authority, which contrasts
> > itself to the society. Because the former penetrates deeper into one's
> > mentality. (Sorry for offtopic)
> 
> That's too deep for me, I'm just an American. 

I can't resist to cite this slogan that I learnt long time ago from
the chinese communists (I really do not remember if it were about Caml
programming guidelines or not):

 Always follow the party's line,
 but don't be afraid to swim against the main stream.

[...]
> It seems that the Caml community mostly indents by two spaces, so if 
> you'd like to be a good neighbor you should do so as well. No one will 
> shun you if you refuse and use four spaces, and your code will still 
> be readable. Well, OK, I'll shun you, but probably noone else :-).

I will shun you also, but probably nobody else. Oh yes, now I remember,
for indentation the chinese slogan was:

 Consistenly use one or two extra spaces when indenting,
 but fill free to indent as you like it.

(Sorry for not being so serious about that (in fact) important subject.)

More seriously: Caml is a language of expressions (not blocks of
instructions), and expressions tend to nest rather deeply. Hence it is
not uncommon to have indentation level growing up to 5 in a regular
program (in some bad cases it could go up to 10). Then suppose you use
4 spaces as indentation: 10 times 4 is 40 and the left margin is in
the middle of the page. That's way too much. That's why people use 2
spaces since 20 spaces in the left margin is ok. Personnaly, I use one
space with some exceptions for 2 spaces indentation (which is
inconsistent, I know it!) for reasons that are explained in the Caml
programming guidelines. (In short, I write 2 spaces to align the |'s
in the pattern matchings of function definitions:

let rec length = function
  | [] ->
  | x :: l ->

but I write one space to indent within an arithmetic expression, if
then else, applications ..., no space at all (or alignment to the
keyword) for pattern matching clauses of try and match.)

However, I use these rules consistently and have made the effort to
write them out with pro and cons arguments, so that you can read those
and design your own consistent set of rules.

Kidding again: evidently, the best you can do is to choose your set of rules
so that it appears to be exactly ours (a variation on the chinese
slogan for indentation :)

> Its wise to invest some time reading the compiler sources. I wish I had
> done so earlier. 

Absolutely.

> -- Brian
> 
> PS: It would be useful to have the programming guidelines extended to
>     cover programming with classes and modules. 

I added some paragraph on modules. May be you can tell me what topics
I have to add or extend about modules ? For classes, I'm a bit more
puzzled and I need help from people that use classes more than I do,
and that already know what are the problems to avoid and the styles to
recommend.

Waiting for your helpful comments and suggestions,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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

Re: [Caml-list] indent 2

[Brian Rogoff]

No idea why I was specifically addressed for this, but since you ask...

On Sat, 21 Jul 2001, Alexander V. Voinov wrote:
> Hi Damien,
> 
> Damien Doligez wrote:
> > 
> > >From: "Alexander V. Voinov" <avv@quasar.ipa.nw.ru>
> > 
> > >Is the indentation with the step 2 a _must_ for those who program in
> > >OCaml? I got used 4, and already set all the necessary variables for
> > 
> > Hey, the Soviet Union doesn't exist any more.  Welcome to the free
> > world, comrade.
> 
> Oh, if it were that simple. The pressure of the society may be much
> stronger than the pressure of an external authority, which contrasts
> itself to the society. Because the former penetrates deeper into one's
> mentality. (Sorry for offtopic)

That's too deep for me, I'm just an American. 

When I first started programming seriously with lots of other people
reading and modifying programs that I wrote, people would argue a lot
about non-issues like where to put the braces. My basic rule is that 
I'd like the programs to look as though they'd been written by one person, 
with a consistent style. I can basically adapt to anything and in two 
weeks or so a new style will seem normal. I note that the new guidelines 
Pierre mentions say much the same thing 

  Choose a generally accepted style of indentation, then use it
  systematically throughout the whole application. 

It seems that the Caml community mostly indents by two spaces, so if 
you'd like to be a good neighbor you should do so as well. No one will 
shun you if you refuse and use four spaces, and your code will still 
be readable. Well, OK, I'll shun you, but probably noone else :-).

Its wise to invest some time reading the compiler sources. I wish I had
done so earlier. 

-- Brian

PS: It would be useful to have the programming guidelines extended to
    cover programming with classes and modules. 


-------------------
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

Re: [Caml-list] indent 2

[Alexander V. Voinov]

Hi Damien,

Damien Doligez wrote:
> 
> >From: "Alexander V. Voinov" <avv@quasar.ipa.nw.ru>
> 
> >Is the indentation with the step 2 a _must_ for those who program in
> >OCaml? I got used 4, and already set all the necessary variables for
> 
> Hey, the Soviet Union doesn't exist any more.  Welcome to the free
> world, comrade.

Oh, if it were that simple. The pressure of the society may be much
stronger than the pressure of an external authority, which contrasts
itself to the society. Because the former penetrates deeper into one's
mentality. (Sorry for offtopic)

In this particular case the concern is that my (supposedly genious :-)
sources would not be readable by the OCaml community, and while I'm not
yet got used to any particular style I can accept some widely adopted.

Alexander
-------------------
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

Re: [Caml-list] indent 2

[Damien Doligez]

>From: "Alexander V. Voinov" <avv@quasar.ipa.nw.ru>

>Is the indentation with the step 2 a _must_ for those who program in
>OCaml? I got used 4, and already set all the necessary variables for

Hey, the Soviet Union doesn't exist any more.  Welcome to the free
world, comrade.

-- Damien
-------------------
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