Re: [Caml-list] CamlP4 Revised syntax comment

[brogoff@speakeasy.net]

On Tue, 29 Oct 2002, Pierre Weis wrote:
> 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.)

Right, that makes a lot of sense, even though it may be preferable to depart 
slightly from English grammar and just use "is" for both to save a keyword. 

Another place where classic OCaml could be a bit wordier is in the declaration 
of multiparameter data constructors; in Revised the cases of "constructor 
with a tupled parameter" and "constructor with several parameters" are more 
clearly distinguished than in OCaml, and in OCaml this is a gotcha since the 
implementation is different. 

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

Thanks to OCaml, I've forgotten a lot of C ;-), but is this really true? 
The way I understood it, == is just value equality, but it doesn't work 
with structures on account of alignment and packing issues which would make it 
too costly. Since strings and arrays are nothing more than pointers in C, 
== on strings or arrays is just value comparison of pointers. In the latest 
C, which has complex numbers, I'm pretty sure equality is structural, since 
complex numbers get their real and complex parts checked. 

> 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 ``===''.

I hadn't thought of that, and I'm not even sure if you're just pulling my leg, 
but it's a good argument anyways. Is this an abstract point, or has anyone 
really needed a graph equivalence test over recursively defiend values in 
practice? 

-- Brian


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