5

How can I avoid name conflicts among modules? From the documentation, it seems currently there is no principled name management among modules in Rascal. When importing a module, all names declared public in the imported module come into scope. Is there a way for qualified import? Or will there be?

day
  • 2,292
  • 1
  • 20
  • 23

1 Answers1

4

Good question again :-) The short answer is you qualify the names at the use sites in the module that has imported the same name twice.

The long answer is three-fold:

  1. The extend mechanism (as opposed to import) will support renaming at extension time in the future.
  2. When two names clash, in the sense that there is an ambiguity due to importing two modules that use the same name, the name is to be qualified at the use site in the current module. The type checker will suggest something appropriate (when it is released).
    • For example in this ambiguous code: int a = f; (imagine f was imported from both module A and module B), you should write: int a = A::f or int a = B::f to resolve the ambiguity.
  3. For non-overlapping functions, algebraic data-types and syntax non-terminals clashes do not exist, they are merged.
    • For example: data A = a(); from one module is merged with data A = b(), same for syntax syntax Exp = Exp "+" Exp; is merged with syntax Exp = Exp "*" Exp; and for functions: int f(int i) = 1; is merged with int f(real r) = 1;.
    • On that note, you could still refer to one of the alternatives using: A::f(1) to prevent using the merged version.
    • And overlapping functions will still require disambiguation, when the parameter patterns are not mutually exclusive (an example would be: int f(int i) = 1; from one module with int f(value x) = 2; from another.
Jurgen Vinju
  • 6,393
  • 1
  • 15
  • 26
  • 1
    What is the strategy for merging? For data, it does not matter. But for functions, it is a bit tricky. As far as I can tell, function dispatch in Rascal relies on pattern matching which is top down following the sequential order of the function definitions in the source. Then when merging two function definitions from two imported sources, the order of the import statements matter. I strongly suggest Rascal implement the best-fit pattern matching mechanism, which order patterns by specificity. – day Oct 25 '13 at 09:04
  • The order is undefined officially, giving room to the interpreter and compiler to choose an efficient one. Compositions are expected to mutually be exclusive and warnings will be produced eventually if this is not proved to be the case. The `default` keyword can be used to separate two functions definitions that overlap, where the `default` one will be tried only if the non-default does not match. In practice the compiler will do specificity ordering most of the time and the interpreter does something order based but rather unpredictable. – Jurgen Vinju Oct 26 '13 at 09:08