[erlang-questions] where did my code come from?

[Jesper Louis Andersen]

On Tue, Sep 13, 2011 at 09:19, Joe Armstrong <erlang@REDACTED> wrote:
>    -location(lists,
> "https://github.com/erlang/otp/blob/dev/lib/stdlib/src/lists.erl").

>    Comments?

I like the idea quite a lot. In a modern world, the whole notion of "a
module lives on a single file system" is wrong. It is rather the case
that a module lives its life behind an URI, is subject to change and
that locally we are more concerned about caching and having the
correct version. While you are at it, your -location() notion also
allows for import renaming, which is something that is needed dearly
in Erlang. Who says a module is in a file? It could be in an HTTP
stream, or sent over a websocket or XMPP even. There is no reason to
tie it to a specific carrier.

As for security, security is to be had by forming releases. When you
create a release, you can use signatures to verify the authenticity of
modules from module authors. The signature is even present easily in
git with a merkle-tree-like construction. The alternative, which is
probably some 20-30 years out in the future is Proof-carrying-code
where the code itself provides a proof of what it does - so lets stick
with signatures for now.

Releases also provide a stable notion of the system. It is not subject
to change once formed.

Then there is the part of self-documenting the dependencies, which I
also really like. In the Standard ML community, there is a nice MLB
concept where you can form bundles of software in the large. You can
say "This application consists of these files, and it exports these
modules and functors under these (renamed) names". Upon import, you
can also rename the API names to avoid clashes locally. The standard
library is just a MLB application reference. The older standard
library can be had by another reference.

Essentially we have a notion of lexically scoped module availability
and exportation in the MLB files. But they never considered a world
where everything is just an URI. Which is why I like the location
idea. It incorporates that notion, and it is a tighter coupling than
an external MLB file, which I am not sure is the way to go. In any
case, if one were to revamp the module system of Erlang, -location()
should be a consideration.


-- 
J.