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

Joe Armstrong erlang@REDACTED
Tue May 24 22:08:40 CEST 2011


On Tue, May 24, 2011 at 8:36 PM, 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.
>
>
YES - I've made a start on this - the first program is
a segmenter that attempts to destruct a module.

I've just bough a synology DS411 slim with 3TB of RAID 5 storage
so am (finally) writing a backup program, this has first priority
in the hobby dept. Then I have to attack my legacy collection of 40K
erlang modules :-)

Unfortunately information about individual functions is
scattered all over the place. I want the source, the type signature,
the documentation. These are available in a variety of different
formats in different places. Documentation is in untagged comments
in @tagged edoc format or in XML in a completely different file.

I'd like this in one place with defined abstract types for everything

Volunteers ....

Silly design question: if multiple people can edit (say) a wiki
of functions what formatting standards should be enforced?

   - the last person who edited the text
   - some "moderator" (who)
   - by a pretty printer
    (is there a *really good* pp? - with color syntax marking)



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

Easy - it is there already (I think) poke around in beam_lib.erl
this analyses the .beam files.


>
> 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).
>
>
Great

I'll be back ...

/Joe



> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110524/881e3553/attachment.htm>


More information about the erlang-questions mailing list