New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for absolute module path #5849
Comments
Comment author: @gasche There is no clean semantics for this. Consider for example: let module M = struct ... end in
let module M = struct ... end in
.M.foo 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). |
Comment author: @bobzhang for the local module M in file A, its absolute path is .A.M. there's no ambiguity here. |
Comment author: @gasche 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 |
Comment author: @lpw25 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. |
Comment author: @gasche 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? |
Comment author: @bobzhang 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 Ideally, when the user write such macros which generate |
Comment author: @damiendoligez A note about the proposed syntax: it clashes with record field access, for example:
is ambiguous. Maybe this syntax could work instead:
|
Comment author: @hcarty
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
This is a recurring request. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Original bug ID: 5849
Reporter: @bobzhang
Status: feedback (set by @damiendoligez on 2013-06-28T16:09:18Z)
Resolution: open
Priority: normal
Severity: feature
Category: typing
Has duplicate: #6705
Monitored by: @Drup @diml @hcarty
Bug description
Currently we can not express that we want a module path not from opening statement.
For example
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 statmentsThis feature is helpful to write correct code
The text was updated successfully, but these errors were encountered: