Child modules draft feedback wanted

[Richard A. O'Keefe]

I wrote:
	> This is one of the things that the -export_to(Module, Functions)
	> directive I proposed, oh, must have been in 1997, was to have
	> accomplished.

Mats Cronqvist <mats.cronqvist@REDACTED> asked:
	this is a nice idea. how would it be enforced?
	
There are two people in this office trying to empty it out so that
the carpet layers can come in on Monday morning.  They want to take
the computers away tomorrow morning.  So please forgive me for not
giving a detailed answer.  Oh help, my wife has just run saying she
needs to go to the doctor and I'll have to pick the girls up from
choir.  Here's a quick sketch.  As it happens, it's _not_ what I
really had in mind; it's just to make a point.

Secondly, a call to

    M:F(X1, ..., Xn)

is basically erlang:'_n'(X1, ..., Xn, ?MODULE, F, M).

where
    /* In erlang: */
    '_n'(X1, ...., Xn, Importer, F, mod1) ->
	mod1:'_n'(X1, ..., Xn, Importer, F).

    /* In mod1: */
    '_n'(X1, ..., Xn, _, f) ->
	f(X1, ..., Xn);

	if -export([f/n]) with no restriction.

    '_n'(X1, ..., Xn, mod2, f) ->
	f(X1, ..., Xn);

	if -export_to(mod2, [f/n])

If a module exports a function to more than one other module, you
get more than one clause here, but I expected that to be rare.
I'm also assuming, in this sketch, fast hashed clause selection.

	> "Ulf Wiger \(AL/EAB\)" <ulf.wiger@REDACTED> wrote:
	> [...]
	>	exporting the pseudo function record_info/2 would 
	>	mean that some helper code could be written a lot 
	>	more cleanly.

This confused me, because it had never occurred to me that this
function wasn't already exported, AND because the context was
EXPORTING RECORD DECLARATIONS SO THEY COULD BE USED AS RECORD SYNTAX.
Apparently there was a change of subject here which I didn't pick up,

	   this paragraph is confusing me.
	   the function mod1:record_info(fred) tells you what mod1 thinks fred looks 
	like. how is that confusing?

Because who is "you"?  Because if you are *expecting* to get records from
fred, why don't you *know* why they look like?  Because this can expose
details about record structures that fred has no intention of revealing
to any other module.  And so on.

	   btw, the "helper code" ulf refers to is a tool i wanted to
	write for the AXD.  the tool would query all modules in the
	system about what they think various records looks like, and
	warn about discrepancies.  (in our build system it's entirely
	possible that mod1 and mod2 both use #fred, but disagree on its
	definition.)

That's nice, but it is something you can _already_ do, no?  Not trivially,
but as long as you have the .beam files, it's _possible_ to get that
information.

Records are wrong.  That's the problem.  They just don't "fit" the way
Erlang does things, and never did.