Re: [Caml-list] CamlP4 Revised syntax comment

[Pierre Weis <pierre.weis@inria.fr>]

>     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
equality.)

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

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

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
efficiently.)

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, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners