[sestep]

I'm probably just missing something obvious, but in this scenario with really long names, doesn't that just mean all code will be extremely verbose? Or are you saying there'd be some way to have shorter bindings to those longer names within a specific context? But then what would that look like? Typically we use modules to denote contexts within which you can import longer fully-qualified names with shorter aliases.

[greener_grass]

You would do something like:

    open universe.mega_corp.finance_dept.team_alpha

Then when you use `foo`, the compiler would know you mean `universe.mega_corp.finance_dept.team_alpha.foo`.

There will probably need to be some kind of lock-file or hash stored with the source-code so that we know precisely which version of `universe.mega_corp.finance_dept.team_alpha.foo` was resolved.

[j_w]

This is literally just

  using universe.mega_corp.finance_dept.team_alpha;

Every argument made quickly becomes invalid because in any sufficiently complex project, the function naming scheme will end up replicating a module/namespace system.

[greener_grass]

Very few languages let you have multiple versions of the same package in one project; fewer let you use functions from both versions together; and even fewer make this easy!

This is something that would be enabled with hash identifiers and no modules:

    let foo_1 = [e-mail]
    let foo_2 = [e-mail]

    let compare_old_new_foo(x) =
      foo_2(x) - foo_1(x)

There would be a corresponding lock-file to make this reproducible:

    {
      "universe.mega_corp.finance_dept.team_alpha": {
        "v1.0.0": "aabbcc",
        "v2.0.0": "xxyyzz"
      }
    }

I think this is pretty neat!

[ramses0]

This is kindof how golang works by default. `import foo/bar/baz` then "foo" and "bar" effectively don't exist, you only refer to "baz" in the end.

`import github.com/blah/baz`, `megacorp.com/finance/baz`, ...

It all resolves to `baz.Something()`