Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path hanger extern instead of crate declarations #49

Closed
Tracked by #14
fmease opened this issue Dec 9, 2020 · 1 comment
Closed
Tracked by #14

Path hanger extern instead of crate declarations #49

fmease opened this issue Dec 9, 2020 · 1 comment
Labels
A-module-system Area: Module system A-name-resolution Area: Name resolution A-syntax Area: Syntax T-proposal Type: Proposed feature which might not actually be accepted

Comments

@fmease
Copy link
Owner

fmease commented Dec 9, 2020

Remove crate declarations (crate my-lovely-library) from the language and replace them by paths beginning with the path hanger external crates extern being a new keyword (extern.my-lovely-library).

Conceptually, we now have two roots in the module system: crate for the current crate being compiled(…) and crates for all the --linked library dependencies. For the purpose of documentation, let me inform you that before, we only had one – crate – and dependencies would be mounted into this single tree with duplicate crate declarations linking to the identical crate.

Motivations

  • (original motivation) Allows macros, lowering passes, synthesizers of the type inference engine to generate self-contained expressions even if they need to refer to external crates, especially the standard library core!. Before, those would need to somehow inject a crate declaration somewhere close with a hygienic name. Horrendous! One example: Lowering sequence literals. Another one: Derive macros.
  • Crate declarations are inconsistent with external module declarations in the regard how duplication is handled: External module declarations copy content, crate declarations _link`
  • Allows to use bindings from an external crate directly with a single declaration (a use declaration) instead of two (a crate and a use declaration)
  • Is more in line with the notion that external modules are added to your projects from the outside (whether that's a good thing or not) with --link or the crate manifest package.json5, rather than declared by the current crate (which might lead to the assumption that crate metadata is or should be in code like @(version ">=2.3.2") crate extension (whether that's a good thing or not))

Example

Currently

crate awesome
use awesome.Alpha

Beta: Type = Alpha Type

module sub =
    use crate.awesome

    gamma: … = awesome.stuff 0

module mu =
    module nu =
        crate awesome

        X: Type = awesome.f …

Then

use extern.awesome.Alpha

Beta: Type = Alpha Type

module sub =
    gamma: … = extern.awesome.stuff 0 ;; or `crate.awesome.stuff`

module mu =
    module nu =
        X: Type = extern.awesome.f … ;; or `crate.`…
@fmease fmease added enhancement A-module-system Area: Module system A-syntax Area: Syntax T-proposal Type: Proposed feature which might not actually be accepted A-name-resolution Area: Name resolution and removed enhancement labels Dec 9, 2020
@fmease fmease mentioned this issue Feb 15, 2021
12 tasks
@fmease fmease changed the title Path hanger external instead of crate declarations Path hanger crates instead of crate declarations Aug 11, 2021
@fmease fmease changed the title Path hanger crates instead of crate declarations Path hanger extern instead of crate declarations Sep 14, 2021
@fmease
Copy link
Owner Author

fmease commented Sep 14, 2021

Closed in #99.

@fmease fmease closed this as completed Sep 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-module-system Area: Module system A-name-resolution Area: Name resolution A-syntax Area: Syntax T-proposal Type: Proposed feature which might not actually be accepted
Projects
None yet
Development

No branches or pull requests

1 participant