mirror of https://github.com/enso-org/enso.git synced 2024-11-28 07:24:03 +03:00

History

Hubert Plociniczak d59714a29d Support module imports using a qualified name (#3608 ) This change allows for importing modules using a qualified name and deals with any conflicts on the way. Given a module C defined at `A/B/C.enso` with ``` type C type C a ``` it is now possible to import it as ``` import project.A ... val x = A.B.C 10 ``` Given a module located at `A/B/C/D.enso`, we will generate intermediate, synthetic, modules that only import and export the successor module along the path. For example, the contents of a synthetic module B will look like ``` import <namespace>.<pkg-name>.A.B.C export <namespace>.<pkg-name>.A.B.C ``` If module B is defined already by the developer, the compiler will _inject_ the above statements to the IR. Also removed the last elements of some lowercase name resolution that managed to survive recent changes (`Meta.Enso_Project` would now be ambiguous with `enso_project` method). Finally, added a pass that detects shadowing of the synthetic module by the type defined along the path. We print a warning in such a situation. Related to https://www.pivotaltracker.com/n/projects/2539304 # Important Notes There was an additional request to fix the annoying problem with `from` imports that would always bring the module into the scope. The changes in stdlib demonstrate how it is now possible to avoid the workaround of ``` from X.Y.Z as Z_Module import A, B ``` (i.e. `as Z_Module` part is almost always unnecessary).	2022-07-29 14:19:07 +00:00
..
src	Support module imports using a qualified name (#3608 )	2022-07-29 14:19:07 +00:00
README.md	Add a markdown style guide (#1022 )	2020-07-21 13:59:40 +01:00

Hubert Plociniczak d59714a29d

Support module imports using a qualified name (#3608 )

This change allows for importing modules using a qualified name and deals with any conflicts on the way.
Given a module C defined at `A/B/C.enso` with
```
type C
type C a
```
it is now possible to import it as
```
import project.A
...
val x = A.B.C 10
```

Given a module located at `A/B/C/D.enso`, we will generate
intermediate, synthetic, modules that only import and export the successor module along the path.
For example, the contents of a synthetic module B will look like
```
import <namespace>.<pkg-name>.A.B.C
export <namespace>.<pkg-name>.A.B.C
```
If module B is defined already by the developer, the compiler will _inject_ the above statements to the IR.

Also removed the last elements of some lowercase name resolution that managed to survive recent
changes (`Meta.Enso_Project` would now be ambiguous with `enso_project` method).

Finally, added a pass that detects shadowing of the synthetic module by the type defined along the path.
We print a warning in such a situation.

Related to https://www.pivotaltracker.com/n/projects/2539304

# Important Notes
There was an additional request to fix the annoying problem with `from` imports that would always bring
the module into the scope. The changes in stdlib demonstrate how it is now possible to avoid the workaround of
```
from X.Y.Z as Z_Module import A, B
```
(i.e. `as Z_Module` part is almost always unnecessary).

2022-07-29 14:19:07 +00:00

src

Support module imports using a qualified name (#3608 )

2022-07-29 14:19:07 +00:00

README.md

Add a markdown style guide (#1022 )

2020-07-21 13:59:40 +01:00

README.md

Package

This library implements and describes the Enso package format used by both the language tooling and the interpreter.