From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id EB25ABB81 for ; Sat, 20 Nov 2004 04:34:30 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iAK3YU7P024687 for ; Sat, 20 Nov 2004 04:34:30 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA05653 for ; Sat, 20 Nov 2004 04:34:30 +0100 (MET) Received: from lakermmtao12.cox.net (lakermmtao12.cox.net [68.230.240.27]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iAK3YTdA029160 for ; Sat, 20 Nov 2004 04:34:29 +0100 Received: from SPIKESHOMEPC ([68.228.151.51]) by lakermmtao12.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041120033427.HHDG8344.lakermmtao12.cox.net@SPIKESHOMEPC> for ; Fri, 19 Nov 2004 22:34:27 -0500 From: "John F. Hughes" To: Subject: Questions on modules Date: Fri, 19 Nov 2004 22:34:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTOsdkVSVHvQT1hT/eu9MOUmOepPw== Message-Id: <20041120033427.HHDG8344.lakermmtao12.cox.net@SPIKESHOMEPC> X-Miltered: at concorde with ID 419EBB46.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 419EBB45.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; struct:01 bindings:01 restrictive:01 foo:01 sig:01 foo:01 struct:01 --john:01 ...:98 signatures:01 functions:01 modules:01 int:01 int:01 variables:02 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: I'm trying to make sense of the module language; I find that there are useful analogies with the "value language" (where there are variables, functions, etc.) It appears that the following are reasonable: 1. "module" has a meaning corresponding to "let"; I see let x = 5;; and module T = struct type t = int let c = 1 end;; as analogous -- both establish bindings for names, more or less. 2. types and signatures are less strongly analogous, because "having a certain type" is more restrictive than "matching a signature", but still, "module type" seems to be analogous to "type". let x:int = 5;; module type FOO = sig type t end;; and module T:FOO = struct type t = int let c = 1 end;; seem analogous as well. But I'm allowed to write let (x:int) = 5 and *not* allowed to write module (T:FOO) = struct type t = int let c = 1 end;; ---- Can someone give me a reason for this design decision? I appreciate your help... --John Hughes