[erlang-questions] Why do we need modules at all?

[Tim Watson]

On this note Joe, in terms of moving the right direction... My
thoughts were that once you've got all that beam code indexed and/or
in memory, it's not a huge step to do what you want because the
underlying infrastructure is already there.

Also I see the approach you're proposing as being a complimentary
and/or alternative to the current status quo, so folks wanting to
carry on as-is will simply make use of the search+download
capabilities without utilising the *edit my code like its a wiki page*
features and so on.

On 24 May 2011 19:36, Tim Watson <watson.timothy@REDACTED> wrote:
> I'd like to propose a "step in the right direction", which won't go
> the whole hog in terms of what Joe is proposing, but would certainly
> move us in (what IMHO is) a good direction and potentially towards
> Joe's vision if he wants to go that far. I know it isn't the whole
> hog, but maybe it's a useful increment towards where we'd like to be.
>
> Why don't we start by building a search engine for finding Erlang
> "stuff" such as OTP applications/libraries, modules and functions.
>
> I would propose that we allow users to search for things by
>
> - kind (e.g., process/gen_thing, modules, functions, whole applications)
> - category (set of arbitrary tags?)
> - type signature (i.e., spec)
>
> I'm guessing this will require patching the compiler to preserve the
> type specs in the beam code. That is something I would need help with,
> but may be trivial for others.
>
> The other things I think you might want are (in no particular order):
>
> 1. binary (code) artefact repository (presumably with a REST/web interface?)
> 2. an means of uploading artefacts (tarballs? .ez archives?) to the repository
> 3. library code for introspecting module metadata (e.g., pulling type
> specs from beam code)
> 4. some means of annotating packages/modules/functions with metadata
> outside of the beam code
> 5. search (indexing, etc) capabilities
> 6. a way to obtain the *things* that you've identified as being useful to you
>
> Not everything will need to be built from scratch. Binary (code)
> artefact repositories already exist (to some extent) in the form of
> CEAN (which has version 2.0 coming out soon IIRC) and the Erlware
> repository. Those tools may not be immediately fit for re-use as they
> come with baggage, but they may be a good base upon which to build
> something for starters.
>
> Other things/ideas might be:
>
> - Integration with build tools (such as rebar) would be useful.
> - Integration with existing search/package-mgmt tools such as agner
>
> You could easily write a plugin that uses epm/agner/sutro to search
> github for something that isn't in the repo, pulls it, builds it and
> adds it. So many possibilities.
>
> I do have other projects on the go, and a job, a family and even a
> social life! Nonetheless, I would be happy to contribute to an
> initiative such as this (or something similarly incremental).
>
>
> On 24 May 2011 19:16, Joe Armstrong <erlang@REDACTED> wrote:
>>
>>
>> On Tue, May 24, 2011 at 6:54 PM, Tom Murphy <amindfv@REDACTED> wrote:
>>>
>>> On 5/24/11, Parnell Springmeyer <ixmatus@REDACTED> wrote:
>>> > In practice though, I would really hate maintaining the metadata for
>>> > every function I've wrote! I much rather group common functions into a
>>> > module and then annotate the module with metadata.
>>>
>>> Ideally, it wouldn't just be just you maintaining the metadata - if
>>> the functions were in the centralized DB, others could suggest or make
>>> changes, wikipedia-style.
>>
>> This did occur to me - the wikipedia allows large numbers of people
>> to make small contributions. Think of what I want as a wiki where each
>> entry is a single erlang function.
>>
>>
>>
>>>
>>> Tom
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>