Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] CamlP4 Revised syntax comment
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-10-29 (11:30)
From: Pierre Weis <pierre.weis@i...>
Subject: Re: [Caml-list] CamlP4 Revised syntax comment
>     I was wondering what Revised users think about replacing comparison = with 
> ==, as in Haskell, and giving phys ref equality some other name? 
>     Why? Well, = is overloaded in OCaml/Revised for both binding and  
> comparison, and this change removes that overloading and uses a 
> fairly common (C, Haskell, Clean,...) symbol == for equality. Physical 
> reference equality should be used rather sparingly anyways so it is better 
> perhaps that it not even be infix. 
>     Besides the extra keystroke, I couldn't think of good reasons why not. 
> Backwards compatibility is not much argument against changes in Revised 
> syntax. 
>     Another possible change along the same lines is having =/= or /= for 
> inequality, which happens to look a little more like the mathematical 
> symbol. 
> -- Brian

To remove overloading of = (predicate and definition symbol), we could
choose to write
  let pat be expression
instead of
  let pat = expression
(And seemingly fro other constructs: type foo is int * int.)

Let's go back to the operators per se.

The choice for operators = and == in Caml was not random, but based on
the semantics: the == operator in C implements physical equality
(hence the need for the strcmp predicate in C); hence, we chose the
same symbol in Caml to denote physical equality.

On the other hand, the = symbol is vastly known as a predicate for
equality that performs a semantic equality rather than a physical
equality (as does the = symbol in maths); hence the natural choice of
= to denote structural equality.

The opposite predicates names were chosen accordingly:
 from C: the negation of == is !=
 from Pascal: the negation of = is <>

You can argue that we do not need those 2 predicates, since you may
think that one ``subsumes'' the other (or is ``more powerful'' than
the other) but sorry, this is not true: we need both predicates to
express both semantics. (Look at the FAQ for a deeper discussion on

You can argue that we do need a third predicate to express even deeper
semantic equality that = can check (say, for instance, equality as
graph equivalence of data), as in the comparison of co-inductive data

To illustrate this situation let's define two ``infinite'' lists of 1s:
let rec x = 1 :: x;;
val x : int list =
  [1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1;
   1; 1; 1; ...]

let rec y = 1 :: y;;
val y : int list =
  [1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1;
   1; 1; 1; ...]

Now, physical equality testing correctly returns false:

# x == y;;
- : bool = false

But structural equality just loops for ever trying to check the
equality of those seemingly infinite lists:

# x = y;;

We thus may need a deeper equality to test graph equivalence! (You can
argue that = could behave like that, but this is not easy to implement

Since this new predicate is inherently costy (we need to keep track of
all already visited nodes), a longer name reminiscent of its equality
semantics could be ``===''.

Hence, we would have:

= is the casual equality
== is the physical equality
=== is the graph equivalence test

Best regards,

Pierre Weis

INRIA, Projet Cristal,,

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: