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 OAA21243; Mon, 28 May 2001 14:51:49 +0200 (MET DST) 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 OAA21359 for ; Mon, 28 May 2001 14:51:48 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f4SCopj08218; Mon, 28 May 2001 14:50:51 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA21320; Mon, 28 May 2001 14:50:50 +0200 (MET DST) Date: Mon, 28 May 2001 14:50:50 +0200 From: Xavier Leroy To: Tyng-Ruey Chuang Cc: caml-list@inria.fr, trc@iiserv.iis.sinica.edu.tw Subject: Re: [Caml-list] weak type variables in module type declarations Message-ID: <20010528145050.E19801@pauillac.inria.fr> References: <200105231324.f4NDOgc28482@mail.iis.sinica.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200105231324.f4NDOgc28482@mail.iis.sinica.edu.tw>; from trc@iis.sinica.edu.tw on Wed, May 23, 2001 at 09:24:42PM +0800 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > O'caml compiler does not seem to recognize user-specified > weak type variables. The compiler, however, will automatically > produce weak type variables when they are needed. > This behavior has been observed and reported as "Id 246" > in the "Known bugs" list (and classified as "not a bug"). There is a small bug, which is that weak type variables as printed by the compiler should not be parse-able as regular type variables. They should be unparseable (e.g. '?a instead of '_a), or at the very least, the compiler should emit a warning when encountering a type variable starting with an _. That there is no syntax for weak variables is a conscious decision, not a bug. "Weak" (non-generalized) variables represent under-constrained types that the type inference algorithm failed to determine, but cannot generalize either. When users put types in module signatures or type constraints, they are expected to put actual, fully-determined types; just leaving "holes" in these types make little sense to me. In particular: > module type SUM = > sig > type ('a, 'b) t = Pink of 'a | Blue of 'b > > val pair : ('_a -> ('_a, '_b) t) * ('_a -> ('_a, '_b) t) > end > module Sum : SUM = > struct > type ('a, 'b) t = Pink of 'a | Blue of 'b > let pair = (id $ (fun a -> Pink a), id $ (fun b -> Pink b)) > end Assuming the _a in SUM are mapped to non-generalized variables, these will be instantiated to actual types ta, tb at the first use of Sum; so why not defining SUM as > module type SUM = > sig > type ('a, 'b) t = Pink of 'a | Blue of 'b > val pair : (ta -> (ta, tb) t) * (ta -> (ta, tb) t) > end Either you need "pair" to be polymorphic, in which case its definition should be eta-expanded, or a monomorphic "pair" is OK, in which case you should give its true type in the signature, as above. I fail to see what good it would make to have '_a variables in the SUM signature. - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr