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

[Joe Armstrong]

On Wed, May 25, 2011 at 2:58 AM, jm <jeffm@REDACTED> wrote:

> On 24/05/11 9:25 PM, Joe Armstrong wrote:
>
>>
>> If we think of modules as containers of functions, then a module is a "set
>> of functions" -
>> my problem is with granularity. The smallest unit of reuse is the module.
>> Suppose my application
>> want just one function from a particular module - I'm forced to load the
>> entire module.
>>
>> This hampers reuse - I *often* read library code and find a single
>> function and cut-and-paste it into
>> my new code. It also discourages sharing - since the smallest unit I can
>> share is a module.
>>
>> The unit of distribution is an application - a set of modules - why this
>> could not be a list of functions
>> I do not know.
>>
>> I think I'd like to view an application as something that offered a
>> message based service that internally
>> was constructed from a set of functions rather than a set of modules.
>>
>>
> Here's a "mad hatter" suggestion. Introduce the concept of a "shadow"
> module. For example, say your using the list module and your after a
> lists:randomise/1. In this proposal you'd have your own lists module, say
> joes_lists,
>
> -module(joes_lists)
>
> randomise(List) ->
>  %% code to randomise the order of the list
>
>
> In you code you would then say,
>
> -shadows(joes_lists, lists).
>
> then use lists:randomise(AList) in your code. The compiler would first
> check the lists module and if the required function didn't exist it would
> use your modules. This would avoid you accidentially overriding the main
> modules definitions which may cause confusion. In such a case, the clash
> should be treated as a compilation error.
>
> The second part would be distribution and release management. There's
> several ways this could be done one would be to have a script which would
> build a set of "patch modules" which would be the cut down versions of your
> own development modules containing only the code and associated
> documentation your using in the current project.
>
>
This is not mad hatter :-)

Knuth mad a patch system years ago. You start off with a file - freeze it so
it's read only
then write patches (replace lines N1,N2 with ...) - he did this with no tool
support.

One problems today is how we work. We make file1
and edit it to file2, of course we can compute a patch P that transforms
file1 to file2.

P works like this:

   P = diff(file1, file2) such that
   patch(file, P) => file2

The problem with  P is that is bears no meaningful semantic information -
there is no intentionality.
many years ago I thought we shuld have thingks like this:

      -module(foo).
      -export([bar/2], ...).
      ...

 This defines foo.erl (as usual)

  Now we define a patch bar.patch

     -patch(bar).
     -insert(foo).
     -insert(baz).
     -delete(foo:bar/2).
     -delete(baz:foo/4).
     -rename(baz:zxy/2, new/2).
     code as before
     ...

     A preprocessor takes bar.patch and makes bar.erl from the patch
instructions.

     This defines a compile time editing operation - insert actually inserts
code from foo.erl, delete
  deletes code ...

    There are just actually simple refactoring commands.

    The *nice* thing about bar.patch is we can preserves intentionality (if
there is such a word) - the
patches produced by diff are usless - this is why a revision control system
want you to comment
every diff. Here the place for comments is in the patch file.

    The above is really trivial to implement

    it would be relatively easy to generate a list of such commands from my
(proposed) folding editor

    -insert(foo, "http://.....") would be very nice

/Joe




> Actually, it might be better to include this as part of the project
> development: execute a script which scans your code repository and the
> -shadow/2 compiler directives and generates the shadow modules as needed.
> This could mean that your custom modules could be kept in a git or mercurial
> repository, on a web server, or in a key-value store. The URLs would then be
> part of the configuration for this script along with version tags, etc. Yes,
> I going to ignore how the modules get in there in the first place.
>
> Jeff.
>
>
>
>
>
> _______________________________________________
> 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/20110525/18740a86/attachment.htm>