[ ] Take a look at module systems of other languages and compile a summary
[ ] re-evaluate the current system which is very close to Rust
[ ] pain point: restricted exposure (public up until certain ancestor)
[ ] hard to implement perfectly (out-of-order, circular, re-exported exposure reaches): we have mostly implemented it except for the useless corner case where the exposure reach is an alias defined as a use-declaration in some other module pointing to the actual reach
[ ] probably not really useful except for @(public topmost) and maybe @(public super) (how often is this feature used in Rust?)
[ ] @(public topmost) is quite useful but very verbose, maybe it should be the default or it should be shortened to @topmost (or something better!)
[ ] pain point: external module declarations: kind of redundant and verbose, could be implied by the file system structure; clashes with module headers a bit (their attributes are merged); could lead to worse error messages though, maybe a new path hanger for those? external module declarations inside of inline module declarations are kind of weird, unusual and unnecessary(?)
[ ] paint point module headers: should they be disallowed in inline module headers?; shares attributes with external module declaration (kind of ugly)
[ ] do we really need the path hanger self? it's rarely useful (mostly useful for use-path-trees)
[ ] do we need re-exports? I think so but Matklad does not; I am quite in favor (shortening paths which would reference private/internal modules; forward compatibility)
[x] #129
[ ] specify new behavior
[ ] implement it
In comparison to your typical file import systems e.g. in JavaScript, Crystal, Python etc, I really like that file imports form a module tree (called a component) where one can access all bindings from ancestor modules irrespective of their visibility. This makes the component feel 'whole'. The difference to the other approach is that less declarations are marked @public and more are marked @(public topmost) (…) since it's not isolated files somehow forming a module tree. But this also requires the a 3-element hierarchy Package>Component >Module instead of just Package>Module (or does the latter not exist anyway? take a look at NodeJS and Cabal Haskell packages which can also contain several tests and executables/binaries in a package next to a library, right?).
@(public topmost)and maybe@(public super)(how often is this feature used in Rust?)@(public topmost)is quite useful but very verbose, maybe it should be the default or it should be shortened to@topmost(or something better!)do we really need the path hanger(mostly useful for use-path-trees)self? it's rarely usefulIn comparison to your typical file import systems e.g. in JavaScript, Crystal, Python etc, I really like that file imports form a module tree (called a component) where one can access all bindings from ancestor modules irrespective of their visibility. This makes the component feel 'whole'. The difference to the other approach is that less declarations are marked
@publicand more are marked@(public topmost)(…) since it's not isolated files somehow forming a module tree. But this also requires the a 3-element hierarchy Package>Component >Module instead of just Package>Module (or does the latter not exist anyway? take a look at NodeJS and Cabal Haskell packages which can also contain several tests and executables/binaries in a package next to a library, right?).