Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] Module abbreviation

6 views
Skip to first unread message

Romain Bardou

unread,
Dec 15, 2009, 11:39:45 AM12/15/09
to caml-list
Hello, dear Caml-list,

I have a file ast.mli. It has no .ml implementation as it contains only
type definitions.

I have a file toto.ml, which contains simply:

module A = Ast

So I only use it as an abbreviation, to write A.t instead of Ast.t for
instance.

However, at link-time, the following error occurs:

File "_none_", line 1, characters 0-1:
Error: Error while linking toto.cmo:
Reference to undefined global `Ast'

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

module type Sig =
sig
type t = ...
...
end

And then, in toto.ml:

module type A =
sig
include Ast.Sig
end

Is there any better way to write such a module abbreviation, without
changing ast.mli? And, of course, without copying or renaming ast.mli
into ast.ml.

By the way, this is yet another evidence for the need of a construction
"sig of" which would take a module (with or without implementation) and
return its signature.

Thanks,

--
Romain Bardou

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Ashish Agarwal

unread,
Dec 15, 2009, 11:57:50 AM12/15/09
to Romain Bardou, caml-list
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. Please double check your
example. It cannot be working as you describe.

Basile STARYNKEVITCH

unread,
Dec 15, 2009, 12:02:00 PM12/15/09
to Romain Bardou, caml-list
Romain Bardou wrote:
> Hello, dear Caml-list,
>
> I have a file ast.mli. It has no .ml implementation as it contains only
> type definitions.


Then you should name that file ast.ml. Last time I tested (more than a year ago) n ast.ml file without corresponding
ast.mli file is handled as if ast.mli was the output of ocamlc -i ast.ml.

Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

David Allsopp

unread,
Dec 15, 2009, 6:28:27 PM12/15/09
to Ashish Agarwal, Romain Bardou, caml-list
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

Ashish Agarwal

unread,
Dec 15, 2009, 10:17:45 PM12/15/09
to David Allsopp, caml-list, Romain Bardou
> 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-...@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:
>

Romain Bardou

unread,
Dec 17, 2009, 6:36:17 AM12/17/09
to Basile STARYNKEVITCH, caml-list
Basile STARYNKEVITCH wrote:
> Romain Bardou wrote:
>> Hello, dear Caml-list,
>>
>> I have a file ast.mli. It has no .ml implementation as it contains only
>> type definitions.
>
>
> Then you should name that file ast.ml. Last time I tested (more than a
> year ago) n ast.ml file without corresponding ast.mli file is handled as
> if ast.mli was the output of ocamlc -i ast.ml.
>
> Regards

Yes, this seems to be the easiest way. It's too bad that this implies
having a .cmo to link against just for some type definitions, though.

Thanks again,

--
Romain Bardou

Basile STARYNKEVITCH

unread,
Dec 18, 2009, 1:57:01 AM12/18/09
to Romain Bardou, caml-list
Romain Bardou wrote:
> Basile STARYNKEVITCH wrote:
>> Romain Bardou wrote:
>>> Hello, dear Caml-list,
>>>
>>> I have a file ast.mli. It has no .ml implementation as it contains only
>>> type definitions.
>>
>> Then you should name that file ast.ml. Last time I tested (more than a
>> year ago) n ast.ml file without corresponding ast.mli file is handled as
>> if ast.mli was the output of ocamlc -i ast.ml.
>>
>> Regards
>
> Yes, this seems to be the easiest way. It's too bad that this implies
> having a .cmo to link against just for some type definitions, though.


Why is that bad? The *.cm[oi] files are the only ones containing the processed type & module information, and we
obviously don't want ocamlc to reparse ast.mli each time it is needed.

Regards

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

_______________________________________________

Romain Bardou

unread,
Dec 18, 2009, 7:06:53 AM12/18/09
to Basile STARYNKEVITCH, caml-list
Basile STARYNKEVITCH wrote:
> Romain Bardou wrote:
>> Basile STARYNKEVITCH wrote:
>>> Romain Bardou wrote:
>>>> Hello, dear Caml-list,
>>>>
>>>> I have a file ast.mli. It has no .ml implementation as it contains only
>>>> type definitions.
>>>
>>> Then you should name that file ast.ml. Last time I tested (more than a
>>> year ago) n ast.ml file without corresponding ast.mli file is handled as
>>> if ast.mli was the output of ocamlc -i ast.ml.
>>>
>>> Regards
>>
>> Yes, this seems to be the easiest way. It's too bad that this implies
>> having a .cmo to link against just for some type definitions, though.
>
>
> Why is that bad? The *.cm[oi] files are the only ones containing the
> processed type & module information, and we obviously don't want ocamlc
> to reparse ast.mli each time it is needed.

Indeed, but a .cmi would be enough :)

Cheers,

--
Romain Bardou

0 new messages