From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA19715 for caml-redistribution; Thu, 21 Jan 1999 09:09:57 +0100 (MET)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA18246 for <caml-list@pauillac.inria.fr>; Wed, 20 Jan 1999 21:02:28 +0100 (MET)
Received: from zarya.maya.com (zarya.maya.com [192.70.254.128])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id VAA09157
	for <caml-list@inria.fr>; Wed, 20 Jan 1999 21:02:25 +0100 (MET)
Received: (from prevost@localhost)
	by zarya.maya.com (8.8.7/8.8.7) id PAA19118
	for caml-list@inria.fr; Wed, 20 Jan 1999 15:03:09 -0500
Message-Id: <199901202003.PAA19118@zarya.maya.com>
Date: Wed, 20 Jan 1999 15:03:09 -0500 (EST)
From: prevost@maya.com
Subject: Class syntax questions
To: caml-list@inria.fr
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: weis

When trying to write an .mli to embody the types of the DOM interface
the other day, I came across what seemed to be a strange wart in the
language spec.

Specifically, I was trying to do something like the following:

type foo_sum =
  | A of a
  | B of b

class type any =
  object
    method to_sum : foo_sum
  end
  
class type a =
  object
    method a : int
  end

class type b =
  object
    method b : bool
  end

(I suspect that the above thing, which acts sort of like "downcasting",
isn't strictly needed to do the things DOM lets you do, since it's also
provided a more reasonable mechanism for accessing children of
different types--but, I want to expose both mechanisms, as the spec
includes them.)

Obviously, the above requires that the types any, a, b, and foo_sum be
corecursive.  Unfortunately, there's no way to use "and" with a class
type and a normal type.  This means that you need to fall back on
writing things like:

type any = < to_sum : foo_sum >
and a = < a : int; to_sum : foo_sum >
and ...

since < .. > notation can't use inherit.  Not too much of a problem
until you're trying to implement something like DOM, which has some
fairly complex interfaces.

In fact, I fear I may have written types doing this which are over large
for the type inference mechanism to handle nicely.  Or maybe not.  IN
any case, the size of the type declarations makes it difficult to find
what O'Caml thinks is wrong.

Is there any way around this in the language, or was it simply
overlooked?

John.