From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id EBC4BBBAF for ; Wed, 16 Dec 2009 04:17:34 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8BAL/fJ0vRVdnaimdsb2JhbACSG4IVhlc/AQEBCgkMBxEFqwCBMYVhiGMBAgMFhCYE X-IronPort-AV: E=Sophos;i="4.47,403,1257116400"; d="scan'208";a="52186692" Received: from mail-gx0-f218.google.com ([209.85.217.218]) by mail4-smtp-sop.national.inria.fr with ESMTP; 16 Dec 2009 04:17:34 +0100 Received: by gxk10 with SMTP id 10so531451gxk.3 for ; Tue, 15 Dec 2009 19:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=7qZ0bIIffEFzLQeS/bYcHzhOxFn8ARnhuf1u+xJ1qx8=; b=WOyLIN4FiQBJcVdn+jFoY6hv/nFKuwQq3hSeFWS/rSnYAnZL9DZdHmIPcRCp5e6QVc 5OZ83SaEBxPhi/NQ2KFDI1Ndqc0Xqoql8H5MmjqbPVzM4NxyF/NGZBi1i9YlJc/QweaK OL09c2hA84hNvkmxV6Qgr8df2pV8hU2RFnCuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=n+Mx+aqgBXjGP+aD5JF2Dg07ynANeUCCJbxTwDBDRQoernnJvSzMnSTKiCwYbR5g2J OwS/0mQUeHchMoACrlxaIAuOrZaKJKPQI/bZc8gzGBd14qp5kW821vWpa7K2ojDvjtDe /kUfC+Z/55kVyqprWfLhoY1wJAx/6WzW/d9tk= MIME-Version: 1.0 Received: by 10.91.197.26 with SMTP id z26mr648370agp.4.1260933452117; Tue, 15 Dec 2009 19:17:32 -0800 (PST) In-Reply-To: <-5655904566200171061@unknownmsgid> References: <4B27BBB4.50006@bardou.fr> <-5655904566200171061@unknownmsgid> From: Ashish Agarwal Date: Tue, 15 Dec 2009 22:17:12 -0500 Message-ID: Subject: Re: [Caml-list] Module abbreviation To: David Allsopp Cc: Romain Bardou , caml-list Content-Type: multipart/alternative; boundary=001636b430627fb784047acff2b6 X-Spam: no; 0.00; abbreviation:01 mli:01 ocaml:01 mli:01 sig:01 cmi:01 ocamlc:01 foo:01 ocaml:01 sig:01 cmi:01 ocamlc:01 foo:01 1975:98 2009:98 --001636b430627fb784047acff2b6 Content-Type: text/plain; charset=ISO-8859-1 > the example given compiles Surprising! I see your point about the types working out, but this also requires the additional assumption that the module type defined by ast.mli will be ascribed specifically to a module named Ast. I suppose this is consistent with how ocaml associates file names with modules so it works out. On Tue, Dec 15, 2009 at 6:28 PM, David Allsopp wrote: > Ashish Agarwal wrote: > > If you only have a file ast.mli, you should not be able to write Ast.Sig > because you do not have a module named Ast. > > This isn't true - the include statement works at a type system level > (because you're dealing with a signature) and therefore only a .cmi file is > required. It does not generate any work for the linker so a module called > Ast is not actually needed when linking. > > > Please double check your example. It cannot be working as you describe. > > I'm afraid you should have checked - the example given compiles (try ocamlc > -o foo ast.mli toto.ml with suitable substitutions for the "..."s) > > Romain Bardou wrote: > > > I have a file ast.mli. It has no .ml implementation as it contains only > > type definitions. > > This is fine > > > I have a file toto.ml, which contains simply: > > > > module A = Ast > > But as this involves a linker instruction you need an actual module - hence > the error you're seeing. I guess you could argue that the module statement > could check to see if Ast only contains type definitions and relax the need > for an actual module but in the general case Ast could contain values and > so > you need a module to link against. > > > I found a workaround, which is to change ast.mli to put all type > > definitions in a signature, such as: > > This workaround works because you take the whole thing back to the type > system so module implementations are not required by the linker. > > > David > > --001636b430627fb784047acff2b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >=A0the example given compiles

Surprising! I see your= point about the types working out, but this also requires the additional a= ssumption that the module type defined by ast.mli will be ascribed specific= ally to a module named Ast. I suppose this is consistent with how ocaml ass= ociates file names with modules so it works out.


On Tue, Dec 15, 2009 at = 6:28 PM, David Allsopp <dra-news@metastack.com> wrote:
Ashish Agarwal wrote:
> If you only have a file ast.mli, you should not be able to write Ast.S= ig
because you do not have a module named Ast.

This isn't true - the include statement works at a type system le= vel
(because you're dealing with a signature) and therefore only a .cmi fil= e is
required. It does not generate any work for the linker so a module called Ast is not actually needed when linking.

> Please double check your example. It cannot be working as you describe= .

I'm afraid you should have checked - the example given compiles (= try ocamlc
-o foo ast.mli toto.ml wit= h suitable substitutions for the "..."s)

Romain Bardou wrote:

> I have a file ast.mli. It has no .ml implementation as it contains onl= y
> type definitions.

This is fine

> I have a file toto.ml= , which contains simply:
>
> module A =3D Ast

But as this involves a linker instruction you need an actual module -= hence
the error you're seeing. I guess you could argue that the module statem= ent
could check to see if Ast only contains type definitions and relax the need=
for an actual module but in the general case Ast could contain values and s= o
you need a module to link against.

> I found a workaround, which is to change ast.mli to put all type
> definitions in a signature, such as:

This workaround works because you take the whole thing back to the ty= pe
system so module implementations are not required by the linker.


David


--001636b430627fb784047acff2b6--