Child modules draft feedback wanted

[Vlad Dumitrescu XX (LN/EAB)]

Hi! 

> -----Original Message-----
> From: Richard A. O'Keefe

> I'm proposing "full" modules as units of hot 
> loading, and "child" modules as units of encapsulation.
>.....
> Being able to split a large module into pieces for editing 
> also means that we can extend version control below the module level.
> If someone wants to edit the sorting routines in lists.erl, 
> why should they have to check out the mapping and filtering 
> functions at the same time?

Just to make sure I understand what you mean. Your child modules would
be similar to traits[1] in OOP, right? I.e. A parametrized[*] set of
methods. In OOP there is a similar dichotomy for classes that should be
both generators of instances (with a lot of functionality) and units of
reuse (small and self-contained).

[*] Parametrization isn't part of your proposal, but I don't see as
unthinkable to use the same mechanism as for 'abstract modules', should
that feature be needed. BTW, does anyone use abstract modules?

[1] See for example
http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf

Quoting from the above,
-------
Traits have the following properties.
- A trait _provides_ a set of methods that implement behaviour.
- A trait _requires_ a set of methods that serve as parameters for the
provided behaviour.
- Traits do not specify any state variables, and the methods provided by
traits never
access state variables directly.
- Classes and traits can be composed from other traits, but the
composition order is
irrelevant. Conflicting methods must be explicitly resolved.
- Trait composition does not affect the semantics of a class: the
meaning of the class
is the same as it would be if all of the methods obtained from the
trait(s) were
defined directly in the class.
- Similarly, trait composition does not affect the semantics of a trait:
a composite trait
is equivalent to a flattened trait containing the same methods.
-------

IMHO this looks almost the same as Richard's proposal. 

> There is no way of 
> marking modules as "private", although the
> 
>     -export_to(Module, [F1/N1, ..., Fk/Nk]).
> 
> directive that I proposed many years ago would make this kind 
> of thing a lot safer and a lot easier to grasp the structure 
> of than it presently is.  

This and child modules/traits and the other related things look to me
like they are part of a general module management functionality. 

Handling it with module attributes works and is relatively easy
implemented, but feels similar to using records vs abstract patterns - a
little too low-level. It might be useful to try to see if having modules
as first-class citizens and another notation would make anything easier
to understand, use and/or implement.

Best regards,
Vlad