Mirror of forum.nim-lang.org

4169 :: [Proposal] Import a with 'b' (<- refers to importing a.xyz as bxyz)

• Allosteric (orginal) [2018-09-02T07:09:30+02:00] view original

  While I like how elegant Nim is, there is one thing which seems, not elegant enough. That is the importing system. I would like to propose a import a with "b" expression which will anable importing a.xyz as bxyz

  Currently, import a will import everything with an * (maybe xyz as an example) and allowing access without a prefix of a.. While this works handy for many aspects, such as Uniform function call syntax, it is troublesome in some occasions.

  1. Identifiers may collide with other modules. In such cases, Nim requires to qualify it with a module., which makes UFCS difficult.
  2. Name resolution is difficult for the code reader. If there are several modules imported at once, it will require an extremely tedeous task to find out where the identifier-of-interest came from.

  As a solution, I would like to propose the import with expression. Of course, the with can be anything. What this enables is to add a prefix (or maybe suffix) to the imported identifiers. For example, every identifier in module a can be used like bxyz if you import a with b.

  While I believe this is a smart solution, I notice some defects.

  1. How to handle operators. It will be lovely if we can call an operator + like +b but Nim doesn't allow alphabets in operators. There are some operators that uses alphabets (e.g. div) so it might not be a very big problem. It also may cause parsing problems.
  2. PascalCase and camelCase problems. If it is an prefix added, it is difficult to handle the convention of "PascalCase for Types, camelCase for others". (if imported with "b" all will be camelCase while with with "B", all will be PascalCase) As a solution, we may use it as an suffix, or maybe the with can be cleaver enough to follow the original form.
  3. IDE and searching. If the module name is included in the identifier, it maybe troublesome for whole word search. It won't be a big problem for IDEs with regex search though.

  Any comments?

---

• Araq (orginal) [2018-09-02T08:53:01+02:00] view original

  Slightly offtopic: I cringe every time I have to read "UFCS". It's called the "method call syntax" or similar. There is nothing universal in a.f(b, c), it puts the first argument in a special position. The universal call syntax is f(a, b, c) or maybe (f a b c) if you like Lisp.

---

• Allosteric (orginal) [2018-09-02T10:30:29+02:00] view original

  Never knew it. Thanks for pointing out. I edited and it's fixed

---

• LeuGim (orginal) [2018-09-02T11:02:25+02:00] view original

  or maybe the with can be cleaver enough to follow the original form

  Yes, it is the easiest part - just to change case of the first letter of the prefix according to identifier, and maybe uppercase identifier's first letter.

  How to handle operators.

  Just to import them as is? Or an optional second (non-alphanumeric) prefix for operators?

---

• Allosteric (orginal) [2018-09-02T11:18:51+02:00] view original

  Thanks for the reply. I have nothing special to say about the case problem.

  Just to import them as is? I can't agree on this since whoever tried to use the import with expression is interested in dividing namespaces.

  optional second (non-alphanumeric) prefix for operators? This seems to be a better idea, and most realistic solution. My concern are

  1. It might cause some lengthy operators
  2. It might breaks some rules (e.g. ^ refers to right-associative)

---

• Libman (orginal) [2018-09-03T05:00:15+02:00] view original

  I still like my old proposal for the use keyword (instead of from ... import nil). Then import means "import into namespace"; use means "use with a prefix".

  Both can be used with the from, except, and as keywords:

  from mymodule import myproc  # put myproc() in global namespace
  from mymodule use myproc     # must use mymodule.myproc()
  
  use mymodule except mybadproc, myotherproc
  use mymodule as m
  
  from mymodule import myproc as mygoodproc
  
  Run

  That last line proposes the ability to specify the name of identifier being imported.

  Like I just said in the dir thread, maybe Nim needs a stdlib module for compile-time module introspection (similar to what nimsuggest does externally).

  You could then combine those two features, (dir and from mymodule [use|import] X as Y) to write whatever macros you want, like:

  import macros
  
  macro importWithPrefix*(moduleName, prefix: string): untyped =
    result = newStmtList()
    for id in dir($moduleName):
      let targetId = $prefix & id
      result.add parseStmt("from " & $moduleName & " import " & id & " as " & targetId)
  
  Run

  (NOTE: just conceptual pseudocode here...)

---