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

[Joe Armstrong]

On Tue, Sep 13, 2011 at 7:21 PM, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED> 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.

YES^10 - given that it can be somewhat tricky to install an application locally
one might want to say

    -location(mod23, "erlmod://a.y.z/foo/bar").

     after which mod23:foo(...) would work via a RPC ton the remote host
could be useful for quick-and-dirty testing or keeping code private


>
> 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.

yes - I made a experiment where I renamed modules with md5(content)
if you see what I mean and signed/encrypted them with RSA keys :-)

>
> 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.
>