0005849: Add support for absolute module path

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.

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

Relationships