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

[Eric Merritt]

>
> When I write the following:
>
>     -module(foo).
>      ...
>     start() ->
>          X = lists:reverse(...),
>          Y = elib1_misc:zap(...)
>          Z = misultin:request(...)
>     ...
>
> I "know" that lists is part of my local OTP install, elib1_misc is my
> own library installed
> in ~/code/elib2_1/ebin and misultin is an imported project stored in
> ~/imports/misultin
> I also know that my paths etc are setup so this code will work when I
> run the program.
>
> The problem is the *nobody else* knows this.
>
> I could tell the system like this:
>
>    -module(foo).
>
>    -location(lists,
> "https://github.com/erlang/otp/blob/dev/lib/stdlib/src/lists.erl").
>    -location(elib1_misc,
> "https://github.com/joearms/elib1/blob/master/lib/src/elib1_misc.erl").
>    -location(misultin,
> "https://github.com/ostinelli/misultin/blob/master/src/misultin.erl").

I would say this is a build system issue more then anything else. In
fact, I would say this is one of the major points of a build system.
Knowing how to assemble your project and where things in your project
live. It could be that the current build systems do a poor job of
advertising this information though.


>    ...
>
>
>   The location annotation give a *definitive source" for the module I
> am using in the module
>
>    What could you do with this information?
>
>    Answer - a lot - for starters
>
>         - automatically check for "latest versions" of libraries
> download them when they change

On compile or at run time? I suspect that changing versions of a
dependency without running associated testing code is going to result
in some interesting and perhaps hard to resolve errors. It could be
possible if the libraries strictly follow semantic versioning and the
'updater', understands patch and minor versions well. However, relying
on a library maintainer to follow a spec without exception is probably
not a good idea. As always the tests tell you the truth of the
viability of a new arrangement of your system (regardless of the new
arrangement).

It could be that auto upgrades happen and all the tests are run and
pass before 'cementing' the new dependencies, I suppose.


>         - provide "who uses my code" feedback to the authors of the code
>         - publish (globally) lists of "definitive" versions of code
>         - recursive track and code dependencies (What do I mean)
>            when my system discovers that I use misultin - it
> downloads misultin.erl
>            misultin.erl will have location dependencies which I can
> follow, thus the libraries
>            that misultin calls can be fetched.
>         - automate code loading

This really does sound much more like a build system then something at
the language level. Though, I suppose you could build the build system
into the platform. It could also just be poor semantics. It could be
that this is what build systems currently do but there is no reason
for that to be in a separate system.


>    Most often this kind of "additional" information is kept "outside
> the program" by strictly
> annotating the program with the location dependencies we bring this
> information *into* the program
> in a form where it cannot be detached from the source code.

You could bring this into the system without actually having to
provide additional annotations to the Erlang source code. Erlang or at
least OTP has quite a lot of metadata that is required to run. These
are first class members of the project/app and are part of the source
code though not part of the Erlang code. I suspect adding a bit of
required metadata could solve this problem without having redundant
declarations in the source code itself.

>
>    Comments?
>
>   /Joe
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>