Child modules draft feedback wanted

[Ulf Wiger (AL/EAB)]

Richard A. O'Keefe
> 
> "Ulf Wiger \(AL/EAB\)" <ulf.wiger@REDACTED> wrote:
> 	Even if the cross-module inlining step were skipped,
> 	exporting the pseudo function record_info/2 would 
> 	mean that some helper code could be written a lot 
> 	more cleanly.
> 
> So you have mod1 that exports (partial) record_info (that is, 
> some records have their information exported, but not 
> others), and mod2 that imports this record_info.

To clarify, I didn't mean supporting the -import_records()
directive, but rather only to export the record_info/2
function. 


> The problem 
> is that without cross- module inlining, that *does* let you 
> enquire about record info at run time, but it does *not* let 
> you *use* any of that information at compile time, so you've 
> imported a record type from mod1, but you can't actually 
> *use* that record type in your source code.


> In that case, you really might as well use abstract patterns.

... which require quite some more implementation effort
before they are available, than for the compiler to 
lay out code for record_info/2 and exporting it.

> 
> 	I see very few disadvantages with doing this,
> 	as the preprocessor has reserved both the name
> 	and semantics of the record_info/2 function.
> 	
> To me it certainly violates the principle of least surprise.
> Here I am writing mod2, and want to use #fred from mod1.  And 
> I am now allowed to import it from mod1, and I'm allowed to 
> ask about it at run time, but I'm not allowed to use it in my 
> source code.  Is that weird or is that really REALLY 
> confusing or what?

I agree that the -import_records/2 directive without 
cross-module inlining would be confusing, but mod1
exporting a function record_info/2 (which anyone is free
to write by hand, except under another name) is hardly
confusing in itself. What the function would say is 
"this is what I (mod1) think a record #fred looks like."

BR,
Ulf W