|Anonymous | Login | Signup for a new account||2014-03-12 19:28 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006324||OCaml||OCaml typing||public||2014-02-07 15:35||2014-02-19 20:25|
|Target Version||Fixed in Version|
|Summary||0006324: Module aliasing and ability to reference the current and parent modules|
|Description||I'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.
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 Information||It's related to http://caml.inria.fr/mantis/view.php?id=6323 [^] |
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).
|Tags||No tags attached.|
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 *)
module Renderer : sig
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 *)
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).
Not being able to reference the current module also means that this (very simple program) doesn't work:
type t = A
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. :-)
|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|
|Copyright © 2000 - 2011 MantisBT Group|