From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA19967; Fri, 14 Dec 2001 17:41:50 +0100 (MET)
X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA19708 for <caml-list@pauillac.inria.fr>; Fri, 14 Dec 2001 17:41:49 +0100 (MET)
Received: from fledge.watson.org (fledge.watson.org [204.156.12.50])
	by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id fBEGfmj10677
	for <caml-list@inria.fr>; Fri, 14 Dec 2001 17:41:48 +0100 (MET)
Received: from localhost (patrick@localhost)
	by fledge.watson.org (8.11.6/8.11.5) with ESMTP id fBEGfkP87843
	for <caml-list@inria.fr>; Fri, 14 Dec 2001 11:41:46 -0500 (EST)
	(envelope-from patrick@watson.org)
Date: Fri, 14 Dec 2001 11:41:45 -0500 (EST)
From: Patrick M Doane <patrick@watson.org>
To: caml-list@inria.fr
Subject: [Caml-list] Module typing
Message-ID: <20011214113557.I86802-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-caml-list@pauillac.inria.fr
Precedence: bulk

I have a question regarding the effect of module interfaces on the typing
of a module.

When a value contains type variables that cannot be generalized, one can
restrict the type in the interface to be monomorphic.

  (* FAILS - type variables that cannot be generalized *)
  module M1 = (
   struct let tbl = Hashtbl.create 31 end
  )

  (* WORKS! *)
  module M2 = (
    struct let tbl = Hashtbl.create 31 end :
    sig    val tbl : (unit,unit) Hashtbl.t end
  )

I'm curious to know why this idea does not extend to work for unbound type
variables in objects:

  (* FAILS - unbound type variables *)
  module O1 = (
    struct class c = object method f x = x end end
  )

  (* ALSO FAILS - unbound type variables *)
  module O2 = (
    struct class c = object method f x = x end end :
    sig    class c : object method f : unit -> unit end end
  )

Any possibilities of this changing in the future?

Thanks for any comments,
Patrick

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr