[erlang-questions] where did my code come from?
Tue Sep 13 09:53:10 CEST 2011
This seems to produce a handful of duplicate and almost duplicate
code. Say, you use 11 modules from a certain external app, and you
need to annotate them all.
For example, such tools as rebar just refer to the application itself,
allowing to download it, update it from external sources, build and
easily include to your code path. What it doesn't provide is, as you
described it, implicit knowledge of where the code comes from for the
programmer. Partially, this can be solved by some rebar-dependent
extensions for vim/emacs/whatever. But, of course, it won't be a
universal solution in any way (we'll have 2 dependency points here:
rebar and editor).
Adding locations as you are suggesting (whether it's done manually, or
semi-automatically) is surely more environment-independent, but looks
So, as for me, I'd rather write a scope plugin for vim that takes
rebar.config into account (probably, the only major Erlang open-source
project that still *doesn't* use rebar is rabbitmq) and allows to
display the given module's location. The rest of the stuff is easily
done by rebar itself.
On Tue, Sep 13, 2011 at 11:19 AM, Joe Armstrong <> wrote:
> I had an idea on my way to work ...
> When you write code, you have *implicit* knowledge of where the
> external code comes from.
> When I write the following:
> 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
> 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:
> 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
> - 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
> 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.
> erlang-questions mailing list
More information about the erlang-questions