English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
interest in a much simpler, but modern, Caml?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-08-12 (23:14)
From: Jon Harrop <jonathandeanharrop@g...>
Subject: RE: [Caml-list] interest in a much simpler, but modern, Caml?
Presumably, in general, that would need to be:


  If Bool.(Int.(x=42) || Int.(x=45)) .


At which point things start to look hairy. To be honest, I see this
delimited overloading as the best of a bad job in the absence of equality
types or per-type functionality. I think what we really want is to be able
to define custom equality, comparison and hashing on types when structural
versions are not applicable. F#'s solution is pretty good. Type classes are
a generalization but I do not see that they buy you much for the added


I'd have thought this (at least equality types) would be worth putting in a
minimalistic language because it is so useful.





From: Jeremy Bem [mailto:jeremy1@gmail.com] 
Sent: 12 August 2010 01:22
To: Jon Harrop
Cc: bluestorm; caml-list List; Florian Weimer
Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml?


On Wed, Aug 11, 2010 at 9:02 AM, Jon Harrop
<jonathandeanharrop@googlemail.com> wrote:


What happens when you do:

 if Int.(x = 42 || x = 45) then ... else ...

Presumably it either barfs on the assumption that "||" refers to bitwise-or
between ints, or we're back to inventing progressively more absurd operator
names for each individual combination of types over which they might work.


How so?  I think this is a borderline case (even in C++, "||" does not refer
to bitwise-or).  But even if Int.(||) *were* defined as some sort of integer
operation, one could simply write:

  if Int.(x = 42) || Int.(x = 45)


Also, I think the discussion has shifted.  For me, the local open is a
reasonably appealing way to stop using OCaml's exotic polymorphic operators
whose behavior depends on the runtime representation and which don't respect
type abstraction.  (For example, ocamllex uses Pervasives.(=) to test
whether Map's are empty, but this breaks if the Map representation changes.)
Moreover the syntax even maintains OCaml compatibility thanks to the recent
update.  But now we seem to be talking about operator overloading, and I'm
just not convinced it's necessary at all in a system with a minimalist


Back to the local opens, I find that I'm hesitant to add so many of them,
especially for equality.  Polymorphic equality is hardly unnatural, after
all (cf. higher-order logic).  I wonder, do any practical languages use
quotient types to implement custom equality predicates?  In principle,
Pervasives.(=) ought to be the "finest" reasonable equivalence relation on a
type, which could then be coarsened:


type foo = Foo of int | Goo of string

let _ = assert (Foo 3 <> Goo "3") (* duh *)

let foo_equiv x y =

  match x, y with

    Foo a, Foo b -> a=b

  | Goo a, Goo b -> a=b

  | Foo a, Goo b

  | Goo b, Foo a -> string_of_int a = b

type goo = foo / foo_equiv (* automatically creates goo_of_foo *)

let _ = assert (goo_of_foo (Foo 3) = goo_of_foo (Goo "3"))


This would require runtime support.  I envision that every "goo" is a block
whose tag is "Quotient_tag" and which stores a "foo_equiv" closure in its
first Obj field.


As it happens, this approach would dovetail with my plans for an integrated
proof assistant.  Of course it lacks the "conservatism" I've been promoting