<div><div class="gmail_quote">On 5 January 2012 15:29, Eric Merritt <span dir="ltr"><<a href="mailto:ericbmerritt@gmail.com">ericbmerritt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
</div></div>Agreed on all most all points, except the module attributes (depending<br>
on what you mean by module attributes). It should be in the beam chunk<br>
data, and absolutely should be returned by module_info. However, I<br>
don't like overloading the attributes chunk with this additional data.<br>
It should be in its own place. Time for an EEP I think.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I didn't make myself very clear there did I. Indeed when I said "attributes" I was referring to what gets returned from module_info/0 rather than the attributes chunk - a separate chunk would be much better. Even better still would be the ability to do module_info(specs). Does the existing module_info return value contain any information about exported types? If not, would you want something like module_info(exported_types) as well?</div>
<div><br></div><div>Also, both dialyzer and PropEr seem to have some concept of a type_server that has utility functions for inspecting and interacting with types. Personally I think a utility module/library (after erl_syntax/erl_syntax_lib and the like) would make for a worthwhile (separate) EEP also.</div>
</div></div>