<div class="gmail_quote"><div>Hi Lukas,</div><div><br></div><div>Thanks for this - some very helpful suggestions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
</blockquote><div><br></div><div>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. :) </div>
<div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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:<br><br>
</blockquote><div><br></div><div>Yes I've used this before. As you say though, it's not a great deal clearer than the match spec itself. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
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.<br>
<div class="im"><br>
</div></blockquote><div><br></div><div>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 <a href="https://github.com/hyperthunk/hamcrest-erlang">https://github.com/hyperthunk/hamcrest-erlang</a> 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. </div>
</div>