[erlang-questions] Type Specs Preserved in Beam Code

[Tim Watson]

On 1 Mar 2012, at 21:16, Kostis Sagonas wrote:

> On 03/01/12 17:46, Tim Watson wrote:
>> Current type specs are only available in beam code if you compile it with debug_info or use the 'abstract_code' parse transform that's floating around on the internet. What are the chances of getting the type spec information preserved in the beam (in a separate chunk) without having to do this?
> 
> It would help if you provided some reasons why compiling with +debug_info is inconvenient for what you would really like to achieve. Recall that the original purpose of BEAM files has been to contain VM byte code and the default setting for them has been to be as compact as possible, so, naturally, chunks other than the one containing byte code have been frowned upon.(*)
> 

Maybe I'm wrong in this, but to me, the type spec is as much a useful part of the function signature as the name and arity. I would like to be able to call Mod:module_info and see type spec information, or maybe 

1> erlang:fun_info(fun lists:map/2).
[{module,lists},
 {name,map},
 {arity,2},
 {env,[]},
 {type,external},
 {spec, ...}]

> However, compiling with +debug_info essentially retains all source in the form of abstract code. Having special chunks with portions of the information which exists in this abstract code (and I am assuming here you want these chunks present by default) does not seem very appealing to me.

Well to be honest I'm probably wrong about special chunks and the fact is I just want the information.

> 
> If there are good reasons to be able to manipulate (the information in) the source, a better alternative would be to ask for abstract code to always be present in .beam files. (I.e., +debug_info by default and a new option like +min_size for environments where the size of beam files is a concern.)
> 

Maybe that's the right thing to do, but I'm not entirely sure there's enough demand. Anyway the use case I have in mind is that

a. I need to introspect the types/specs defined in someone else's module
b. I have no control over how their module was compiled

So just like module attributes are available at runtime regardless of the compiler flags given, I'd like the same for exported types (does this already work? - I haven't checked actually) and for type specs on functions. 

> Kostis
> 
> (*) IMO, this made perfect sense 10+ years ago; not sure this is so relevant a reason nowadays.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions