[erlang-questions] where did my code come from?
Joe Armstrong
erlang@REDACTED
Tue Sep 13 10:01:05 CEST 2011
On Tue, Sep 13, 2011 at 9:53 AM, Dmitry Demeshchuk <demeshchuk@REDACTED> 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 <erlang@REDACTED> 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
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
>
> --
> Best regards,
> Dmitry Demeshchuk
>
More information about the erlang-questions
mailing list