Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005849OCamlOCaml typingpublic2012-12-06 14:582014-12-12 16:44
Reporterhongboz 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005849: Add support for absolute module path
DescriptionCurrently 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
TagsNo tags attached.
Attached Files

- Relationships
has duplicate 0006705resolvedlpw25 Provide a root module that cannot be shadowed 

-  Notes
(0008579)
gasche (developer)
2012-12-06 15:09

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).
(0008580)
hongboz (developer)
2012-12-06 15:18

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.
(0008581)
gasche (developer)
2012-12-06 15:28

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).
(0008582)
lpw25 (developer)
2012-12-06 15:35
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.

(0008583)
gasche (developer)
2012-12-06 15:40

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?
(0008584)
hongboz (developer)
2012-12-06 15:52
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.

(0009639)
doligez (administrator)
2013-06-28 18:09

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.(+)
(0009643)
hcarty (reporter)
2013-06-28 19:32

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

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker