From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p8K1aWIF025583 for ; Tue, 20 Sep 2011 03:36:32 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuABAKDtd07RVdivkGdsb2JhbABCmRqOHwgUAQEBAQkJDQcUJYFTAQEBAwwHAhcVARseAwERCQddAQwBBAEFAQMBU4dVlkSCWAqLQQqCUoU3O4htAgMGhnIEh22LXIYKhng9OYNC X-IronPort-AV: E=Sophos;i="4.68,408,1312149600"; d="scan'208";a="109652152" Received: from mail-qy0-f175.google.com ([209.85.216.175]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Sep 2011 03:36:27 +0200 Received: by qyk10 with SMTP id 10so14587912qyk.6 for ; Mon, 19 Sep 2011 18:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=+Fcv8Y8atVTmb9HReZcRDhwdsOPEwu1dN3XQIvsYeT8=; b=pCPjCNPDQNpCSXYPF/9q2uYoQ7naBJ91KFqpGtEaDe1JEjle5ukGjhOovtIZGzD3xI mSMGBqsjrvwLe6RZRk0PxfvLuMZYC19RUCF6AkCdiyL//nAWrndQ00ASe8iI3aNudnbQ IhLHrIiGYK/A6/FI3OnwQOSZ/YhoWP8iMnb5k= MIME-Version: 1.0 Received: by 10.52.177.7 with SMTP id cm7mr165140vdc.37.1316482585870; Mon, 19 Sep 2011 18:36:25 -0700 (PDT) Received: by 10.220.152.84 with HTTP; Mon, 19 Sep 2011 18:36:25 -0700 (PDT) Reply-To: yminsky@gmail.com Date: Tue, 20 Sep 2011 09:36:25 +0800 Message-ID: From: Yaron Minsky To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=20cf3071ccc4e2427104ad557cbf Subject: [Caml-list] A limitation of "with type" declarations for first-class modules --20cf3071ccc4e2427104ad557cbf Content-Type: text/plain; charset=ISO-8859-1 For some reason, 1st-class modules have more restrictive "with" syntax, which turns out to be a practical problem. The main constraint is that with constraints do not seem to be able to refer to sub-modules. Consider the following code snippet: > module type Foo = sig type t end > module type Bar = sig module Foo : Foo end > > (* compiles *) > let g (type a) (m : (module Foo with type t = a)) = () > > (* fails to compile with a syntax error *) > let f (type a) (m : (module Bar with type Foo.t = a)) = () Of course, ordinary modules have no such constraint. Any thoughts as to what is going on here, and whether it can be fixed? This has really restricted designs I've been using, forcing me to flatten out structures that are more naturally nested. y --20cf3071ccc4e2427104ad557cbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For some reason, 1st-class modules have more restrictive "with" s= yntax, which turns out to be a practical problem.

The main constrain= t is that with constraints do not seem to be able to refer to sub-modules.= =A0 Consider the following code snippet:

>=A0=A0=A0=A0 mo= dule type Foo =3D sig type t end
>=A0= =A0=A0=A0 module type Bar =3D sig module Foo : Foo end
>
>=A0=A0=A0=A0 (* compiles *)
>=A0=A0=A0=A0 let g = (type a) (m : (module Foo with type t =3D a)) =3D ()
>
>=A0=A0=A0=A0 (* fai= ls to compile with a syntax error *)
>= =A0=A0=A0=A0 let f (type a) (m : (module Bar with type Foo.t =3D a)) =3D ()=

Of course, ordinary modules have no such constraint.=A0 Any thoughts as= to what is going on here, and whether it can be fixed?=A0 This has really = restricted designs I've been using, forcing me to flatten out structure= s that are more naturally nested.

y
--20cf3071ccc4e2427104ad557cbf--