[Caml-list] typing mutually recursive classes

[Gabriel Scherer <gabriel.scherer@gmail.com>]

(I previously sent this reply to Christopher privately, by mistake.
Apologies for double-sending.)

I'm no expert of the typing of the object-oriented features of OCaml,
but my understanding is that #foo is a syntactic sugar for the
expansion of foo's type with an added row variable. For example, if
"foo" has the object type < a : int; b : bool >, #foo would be a
synonym for < a : int; b : bool; .. >. For #foo to mean anything,
"foo" must be already defined, so I'm not surprised that it fails when
defining a recursive class. The following already fails:

class test = object
  method id : 'a. (#test as 'a) -> 'a = fun x -> x
end

What would you expand #test to in this definition? On the other hand,
just using "test" makes sense in a recursive type.

Note that you might be able to work around this limitation by using
recursive modules as a way to "pre-declare" the interface of your
classes. The following type-checks:

module rec M : sig
  class element : 'a -> #M.registry -> object
    method registry : M.registry
  end

  class registry : object
    method register : 'a . (#element as 'a) -> unit
  end
end = struct
  class element id (registry : #M.registry) =
  object
    method registry = (registry :> M.registry)
  end

  class registry = object
    val mutable set = []
    method register :'a. (#element as 'a) -> unit =
      fun s ->
        set <- (s :> element) :: set
  end
end

Now, is adding recursive modules to an already too complicated typing
problem a good idea? Frankly, I don't think so. I would personally go
for the version without #foo types and with explicit casting.

On Wed, Oct 24, 2012 at 9:32 PM, Christopher Zimmermann
<madroach@gmerlin.de> wrote:
> On Wed, 24 Oct 2012 20:40:27 +0200
> Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
>
>> I don't really understand what you are trying to achieve with this
>> #foo types.
>
> It's the simplest statement possible to demonstrate the typing error I
> ran into. Even simpler:
>
> class type a = object end
> and b =
>   object
>     method foo: 'a. (#a as 'a) -> unit
>   end
>
>   fails, but
>
> class type a = object end
> class type b =
>   object
>     method foo: 'a. (#a as 'a) -> unit
>   end
>
>
> works fine. Why?
>
>> What would even be the type of "set" in your example? You
>> cannot hold a mutable reference to a polymorphic type (#element list),
>> so I'm not sure what you would have but (element list).
> That's correct. It should read
>   val mutable set = []
>   method register :'a. (#element as 'a) -> unit =
>     fun s ->
>       set <- (s : #element :> element) :: set
>
>> If you're
>> going to coerce your elements into the common (element) supertype
>> anyway, why insist on having flexible bounds? You could just use
>> (registry) and (element), coerce when needed (foo :> element), and get
>> rid of those pesky typing issues.
>
> That's my current workaround for this issue. But I would prefer a
> solution where the coercion happens in the registry.
>
>>
>> On Wed, Oct 24, 2012 at 8:03 PM, Christopher Zimmermann
>> <madroach@gmerlin.de> wrote:
>> > Hi,
>> >
>> > I have a problem with typing a system of mutually recursive classes.
>> >
>> > This piece of code fails to compile:
>> >
>> > class a =
>> >   object end
>> > and b =
>> >   object
>> >     method foo: a -> int =
>> >       fun s -> 3
>> >   end;;
>> >
>> > Error: The universal type variable 'a cannot be generalized:
>> >        it escapes its scope.
>> >
>> >
>> > But this compiles fine:
>> >
>> > class a =
>> >   object end
>> > class b =
>> >   object
>> >     method foo: 'a. (#a as 'a) -> int =
>> >       fun s -> 3
>> >   end;;
>> >
>> >
>> > What I actually want to do is this:
>> >
>> > class element id (registry :#registry) =
>> >   object
>> >     method registry = registry
>> >   end
>> >
>> > and registry =
>> >   object
>> >     val set = []
>> >     method register :'a. (#element as 'a) -> unit =
>> >       fun s ->
>> >         set <- s :: set
>> >   end
>> >
>> >
>> > Any ideas how to do this without parametrizing the classes?
>> >
>> > Christopher