[erlang-questions] getting type info at runtime

Tim Watson watson.timothy@REDACTED
Tue Sep 27 00:57:09 CEST 2011


Hi Lukas,

Thanks for this - some very helpful suggestions.


> Regarding types in .beam files: That information is only part of the
> abtract code, so dialyzer, hipe and all other tools need the abtract code or
> the source code to do its magic. The reason why it is stripped out is
> because the .beam files should be as small as possible by default and also
> partly because you cannot trust a typespec to be correct.
>

Yes I can understand wanting to keep the beam small, but it would be nice to
have the option of the compiler inserting the type specs and of course just
because the type spec is in the beam file, doesn't mean it has to be brought
into memory when loading the beam. :)

If abstract_code is the only sane way to go then I can simply push out
warnings for beams that don't have it and exclude those from the
introspection.

Describing where you want to put your instrumentation is harder to figure
> out though and to date no one really has managed to write a good wrapper to
> match specs. The best one (imo) is the dbg:fun2ms function Eg:
>
>
Yes I've used this before. As you say though, it's not a great deal clearer
than the match spec itself.


>
> Using the improved -specs that will come in R14B04 it would be possible to
> write a spec which describes the same thing. Keeping things in Erlang has
> the advantage of it being easier to build tools around it though.
>
>
I haven't seen these, so I'll have a poke around and see how they work. In
terms of actually writing the specification, I think you're right that
having something pure erlang is good. I was pondering the approach I used
for https://github.com/hyperthunk/hamcrest-erlang of using various functions
as sugar. Ultimately though, I'd like to be able to put the instrumentation
config used by the build into a config file (such as rebar.config) so it
will probably end up either looking like a match spec or being a string that
gets parsed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110926/568aae62/attachment.htm>


More information about the erlang-questions mailing list