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

Joe Armstrong <>
Tue Sep 13 10:01:05 CEST 2011


On Tue, Sep 13, 2011 at 9:53 AM, Dmitry Demeshchuk <> wrote:
> 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.

-include("dependencies"). :-)

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

But it's *precise* - do you want precision or convenience?

It's actually the shortest possible way to *exactly* specify
what the symbol (for example lists) means

If I say

 -location(lists,
 "https://github.com/erlang/otp/blob/dev/lib/stdlib/src/lists.erl").

I mean the module lists is to be found at exactly this address

If several modules had the same base address I could use a macro -
but this does alter the semantics

>
> 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:
>>
>>     -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").
>>
>>    ...
>>
>>
>>   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.
>>
>>    Comments?
>>
>>   /Joe
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
>
> --
> Best regards,
> Dmitry Demeshchuk
>



More information about the erlang-questions mailing list