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

Bengt Kleberg bengt.kleberg@REDACTED
Wed Sep 14 08:46:16 CEST 2011


This email mentions import renaming. Does that include solving the
problem that two modules I want to load have the same name?


On Tue, 2011-09-13 at 19:21 +0200, Jesper Louis Andersen wrote:
> 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.

More information about the erlang-questions mailing list