|Anonymous | Login | Signup for a new account||2015-03-04 12:15 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005849||OCaml||OCaml typing||public||2012-12-06 14:58||2014-12-12 16:44|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0005849: Add support for absolute module path|
|Description||Currently we can not express that we want a module path not from opening statement.|
it still has the chance that it is from 'open M' which M has a nested module named Pervasives.
I propose a syntax .Pervasives.(+), then when we resolve the identifier here, it will not look up from existing opening statments
This feature is helpful to write correct code
|Tags||No tags attached.|
There is no clean semantics for this. Consider for example:
let module M = struct ... end in
let module M = struct ... end in
What should .M denote in this case?
On the other side, I think it would be possible to denote not modules, but *compilation units*. Despite being currently identified with modules from the OCaml source code point of view, they live in a different namespace (distinct from internal modules) that is fixed at compiler invocation time (ocamlc ...) and does not evolve during the type-checking of a module (save unspecified filesystem update races).
for the local module M in file A, its absolute path is .A.M. there's no ambiguity here.
distinct by compilation units may also work, but my proposal is relatively easy to implement in the trunk.
So you would make a (recursive on the surface, not in semantics) reference to .A.M from inside a.ml?
I think what you're suggesting effectively correspond to having a syntax to denote compilation units (viewed as modules) that is distinct from the usual module-path syntax (for compilation units or internal modules, in the typing environment updated by `open` and local declarations).
edited on: 2012-12-06 15:36
This problem would probably be better solved with simple namespaces, which would allow Pervasives to be referred to by some longer name (e.g. OCaml.Builtin.Pervasives).
Technically a user could override OCaml.Builtin.Pervasives, but technically a user could override :: or true: I don't think that it would be worth worrying about.
In fact some users explicitly override Array to divert the syntactic sugar a.(i), a.(i) <- foo for their own purposes. I think there is an important semantic difference between naming schemes that can be voluntarily overriden and those that cannot -- but I'm not sure there are reason to pick the latter ones, as removing shadowing usually restricts expressivity.
hongboz, could you give an example where it is really important that a name cannot be overriden? Are there real uses cases for such a feature, or does Leo's "long name" suggestion fit the bill as well?
edited on: 2012-12-06 15:52
gasche, yes, but it's easy to reject .A.M from a.ml, the current compilation unit name is already recorded in the trunk.
lpw25, my suggestion is to reject the overriding explicitly except only when you supply different .cmo or .cma files.
My suggestion will not break existing programmers, you can still overriding Array or do anything you want, but for serious programmers, they can express the absolute module names as well.
This is helpful to do robust meta-programming. for example, when you generate an Ast
'let f a b = a+b;;' theoretically, this is dangerous, since the user could override the '+' behavior,
but if we have absolute path, then we can generate an Ast 'let f a b = .Pervasives.(+) a b' whose semantics will not be changed by the context where it is used.
Ideally, when the user write such macros which generate 'let f a b = a + b' could be resolved in the define time to 'let f a b = .Pervasives.(+) a b' . Such proposal provides a chance to implement hygenic macros.
A note about the proposed syntax: it clashes with record field access, for example:
map .Pervasives.exit [()]
is ambiguous. Maybe this syntax could work instead:
|_.Pervasives also has the benefit of being easier to see than .Pervasives when reading code.|
|2012-12-06 14:58||hongboz||New Issue|
|2012-12-06 15:09||gasche||Note Added: 0008579|
|2012-12-06 15:18||hongboz||Note Added: 0008580|
|2012-12-06 15:28||gasche||Note Added: 0008581|
|2012-12-06 15:35||lpw25||Note Added: 0008582|
|2012-12-06 15:36||lpw25||Note Edited: 0008582||View Revisions|
|2012-12-06 15:40||gasche||Note Added: 0008583|
|2012-12-06 15:52||hongboz||Note Added: 0008584|
|2012-12-06 15:52||hongboz||Note Edited: 0008584||View Revisions|
|2013-06-28 18:09||doligez||Note Added: 0009639|
|2013-06-28 18:09||doligez||Status||new => feedback|
|2013-06-28 19:32||hcarty||Note Added: 0009643|
|2014-12-12 11:52||lpw25||Relationship added||has duplicate 0006705|
|Copyright © 2000 - 2011 MantisBT Group|