Skip to content
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

Closed
vicuna opened this issue Dec 6, 2012 · 11 comments
Closed

Add support for absolute module path #5849

vicuna opened this issue Dec 6, 2012 · 11 comments

Comments

@vicuna
Copy link

vicuna commented Dec 6, 2012

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

Pervasives.(+)

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

@vicuna
Copy link
Author

vicuna commented Dec 6, 2012

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).

@vicuna
Copy link
Author

vicuna commented Dec 6, 2012

Comment author: @bobzhang

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.

@vicuna
Copy link
Author

vicuna commented Dec 6, 2012

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 open and local declarations).

@vicuna
Copy link
Author

vicuna commented Dec 6, 2012

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.

@vicuna
Copy link
Author

vicuna commented Dec 6, 2012

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?

@vicuna
Copy link
Author

vicuna commented Dec 6, 2012

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
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.

@vicuna
Copy link
Author

vicuna commented Jun 28, 2013

Comment author: @damiendoligez

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.(+)

@vicuna
Copy link
Author

vicuna commented Jun 28, 2013

Comment author: @hcarty

_.Pervasives also has the benefit of being easier to see than .Pervasives when reading code.

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 15, 2020
@garrigue
Copy link
Contributor

This is a recurring request.

@github-actions github-actions bot removed the Stale label Jun 22, 2020
@github-actions
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants