<br><br><div class="gmail_quote">On Wed, May 25, 2011 at 2:58 AM, jm <span dir="ltr"><<a href="mailto:jeffm@ghostgun.com">jeffm@ghostgun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 24/05/11 9:25 PM, Joe Armstrong wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
If we think of modules as containers of functions, then a module is a "set of functions" -<br>
my problem is with granularity. The smallest unit of reuse is the module. Suppose my application<br>
want just one function from a particular module - I'm forced to load the entire module.<br>
<br>
This hampers reuse - I *often* read library code and find a single function and cut-and-paste it into<br>
my new code. It also discourages sharing - since the smallest unit I can share is a module.<br>
<br>
The unit of distribution is an application - a set of modules - why this could not be a list of functions<br>
I do not know.<br>
<br>
I think I'd like to view an application as something that offered a message based service that internally<br>
was constructed from a set of functions rather than a set of modules.<br>
<br>
</blockquote>
<br></div>
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,<br>
<br>
-module(joes_lists)<br>
<br>
randomise(List) -><br>
%% code to randomise the order of the list<br>
<br>
<br>
In you code you would then say,<br>
<br>
-shadows(joes_lists, lists).<br>
<br>
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.<br>
<br>
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.<br>
<br></blockquote><div><br>This is not mad hatter :-)<br><br>Knuth mad a patch system years ago. You start off with a file - freeze it so it's read only<br>then write patches (replace lines N1,N2 with ...) - he did this with no tool support.<br>
<br>One problems today is how we work. We make file1<br>and edit it to file2, of course we can compute a patch P that transforms file1 to file2.<br><br>P works like this:<br><br> P = diff(file1, file2) such that<br> patch(file, P) => file2<br>
<br>The problem with P is that is bears no meaningful semantic information - there is no intentionality.<br>many years ago I thought we shuld have thingks like this:<br><br> -module(foo).<br> -export([bar/2], ...).<br>
...<br><br> This defines foo.erl (as usual)<br><br> Now we define a patch bar.patch<br><br> -patch(bar).<br> -insert(foo).<br> -insert(baz).<br> -delete(foo:bar/2).<br> -delete(baz:foo/4).<br> -rename(baz:zxy/2, new/2).<br>
code as before<br> ...<br><br> A preprocessor takes bar.patch and makes bar.erl from the patch instructions.<br><br> This defines a compile time editing operation - insert actually inserts code from foo.erl, delete<br>
deletes code ...<br><br> There are just actually simple refactoring commands.<br><br> The *nice* thing about bar.patch is we can preserves intentionality (if there is such a word) - the<br>patches produced by diff are usless - this is why a revision control system want you to comment<br>
every diff. Here the place for comments is in the patch file.<br><br> The above is really trivial to implement<br><br> it would be relatively easy to generate a list of such commands from my (proposed) folding editor<br>
<br> -insert(foo, "http://.....") would be very nice<br><br>/Joe<br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
<br>
Jeff.<div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>