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 RAA29831 for caml-red; Mon, 16 Oct 2000 17:01:51 +0200 (MET DST)
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 OAA27438 for <caml-list@pauillac.inria.fr>; Mon, 16 Oct 2000 14:42:14 +0200 (MET DST)
Received: from nef.ens.fr (nef.ens.fr [129.199.96.32])
	by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e9GCgDP21013
	for <caml-list@inria.fr>; Mon, 16 Oct 2000 14:42:13 +0200 (MET DST)
Received: from basilic.ens.fr (basilic.ens.fr [129.199.99.48])
          by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id e9GCgDM14591
          for <caml-list@inria.fr>; Mon, 16 Oct 2000 14:42:13 +0200 (CEST)
Received: from localhost by basilic.ens.fr (8.9.2/jb-1.1)
	id OAA25599 for <caml-list@inria.fr>; Mon, 16 Oct 2000 14:42:11 +0200 (MET DST)
X-Authentication-Warning: basilic.ens.fr: monniaux owned process doing -bs
Date: Mon, 16 Oct 2000 14:42:11 +0200 (MET DST)
From: David Monniaux <David.Monniaux@ens.fr>
X-Sender: monniaux@basilic.ens.fr
To: Liste CAML <caml-list@inria.fr>
Subject: generalization in tuples
Message-ID: <Pine.GSO.4.03.10010161015350.24630-100000@basilic.ens.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: weis@pauillac.inria.fr

(En français: pourquoi ne pas généraliser le type d'un tuple pour cause de
non-généralisabilité d'une des parties du tuple si de toute façon les
variables de type à généraliser n'y interviennent pas?)

Some typing problem has been bothering me for the week-end.

Let us consider the following code:
# let extractor f = f ~foo:"aaa" ~bar:"bbb";;
val extractor : (foo:string -> bar:string -> 'a) -> 'a = <fun>
# let grostruc = List.map string_of_int [1; 2; 3];;
val grostruc : string list = ["1"; "2"; "3"]
# let zoinx = grostruc, extractor;;
val zoinx : string list * ((foo:string -> bar:string -> 'a) -> 'a) =
  ["1"; "2"; "3"], <fun>

Very logical, and what I wanted: a tuple with some big computed stuff in
the first member and a polymorphic function in the second (this is of
course a simplified example of the actual production code).

Now I do not want to pollute my namespace defining extractor and grostruc,
since all I'm interested in is zoinx.

# let bidule = let extractor f = f ~foo:"aaa" ~bar:"bbb" and grostruc =
List.map string_of_int [1; 2; 3] in grostruc,extractor;;
val bidule : string list * ((foo:string -> bar:string -> '_a) -> '_a) =

The function application in the definition of grostruc prevents 'a from
being generalized. This code is nevertheless equivalent to the precedent
one except from the namespace pollution.

So I actually have two questions:

1/ Is it possible to do what I want to do, even if it means using a
kludge? The above code, using multiple let's, is not good: it's not
useable in the middle of an expression (this is for CamlP4-generated
code).

(acceptable kludges include the use of Obj.magic)

2/ Is there a finer notion of a "generalizable" expression that
encompasses the above code, and could the "let generalization" procedure
in the compiler be improved so that the above code gets a polymorphic
type?

David Monniaux            http://www.di.ens.fr/~monniaux
Laboratoire d'informatique de l'École Normale Supérieure,
Paris, France