Version française
Home     About     Download     Resources     Contact us    
Browse thread
Module abbreviation
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Ashish Agarwal <agarwal1975@g...>
Subject: Re: [Caml-list] Module abbreviation
> 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 <dra-news@metastack.com>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
>
>