Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006324OCamlOCaml typingpublic2014-02-07 15:352014-07-16 15:29
Assigned To 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0006324: Module aliasing and ability to reference the current and parent modules
DescriptionI've always wanted to be able to reference the current module, which also means being able to reference the parent module(s).

An idea is to be allowed to prefix a type or a variable with the current module's name.
As in
    module X = struct type t = A let a : X.t = A end
However this would probably break existing programs, or worse: change their semantics, so let's drop it.

*But* by using a new syntax, we could have this without breaking preexisting programs:
    module X as Y = struct type t = A let a : Y.t = A end
and I believe it would be quite useful!

Perhaps the keyword "as" is not the best, that can certainly be discussed.
Additional InformationIt's related to [^]
as this feature would allow the programmer to fairly easily solve an impossible problem (i.e., the fact that currently some working .ml files just cannot have an .mli that matches its full interface).
TagsNo tags attached.
Attached Files

- Relationships
related to 0006323acknowledged ocamlc -i can generate a wrong signature 

-  Notes
dbuenzli (reporter)
2014-02-07 16:16

I'm having this problem right at the moment where I need to reorder things in a non natural way documentation wise. Below I would like to be able to put Renderer.Buf before Renderer.Private in the generated docs. I'm not able to do so because Renderer.Private uses module type of Buf and I'm not able to tell him I want the toplevel one.

module Buf : sig (* A buffer module, the client does need a renderer to use them *)
   type t

module Renderer : sig
   type t

   module Private : sig
      module Buf : sig (* used by renderer backends may need renderers
        include module type of Buf

   module Buf : sig (* a few Buf functions for clients that need a renderer to work *)
gasche (developer)
2014-02-07 16:36

I personally find this rather ugly, and in my experience this kind of hacks does not generalize very well. For example, if you expect Y.t (for a private t) to refer to the external view of t (say in the context of the work by Grégoire, Jacques and Alain on runtime type representations), this is useful but you quickly end up wanting to be able to name this type also "from the point of view of further sealings", eg. when (X : S') is later used in the source.

This could be useful to speak about the double-vision problems in recursive module (where there really is a canonical sealing we're talking about).
pw374 (reporter)
2014-02-07 16:46

Not being able to reference the current module also means that this (very simple program) doesn't work:

type t = A
open String
let x : t = A

And I've found this very annoying for at least 8 years.

N.B. One could argue that 'open' should only be used before any type declaration (and I'd agree), but it's not forbidden to do so, so it doesn't change anything. And this is only a trivial toy example, so let's not be tempted by stating that it represents how people do or don't program. :-)

- Issue History
Date Modified Username Field Change
2014-02-07 15:35 pw374 New Issue
2014-02-07 16:16 dbuenzli Note Added: 0010913
2014-02-07 16:36 gasche Note Added: 0010914
2014-02-07 16:46 pw374 Note Added: 0010915
2014-02-19 20:25 doligez Relationship added related to 0006323
2014-07-16 15:29 doligez Status new => acknowledged

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker