[erlang-questions] getting type info at runtime

Tim Watson watson.timothy@REDACTED
Tue Sep 27 18:30:55 CEST 2011

On 27 September 2011 16:53, Daniel Luna <daniel@REDACTED> wrote:

> The checking is all done in core erlang, which unfortunately ruins
> readability quite a bit.
I've been meaning to learn core properly anyway.

> You can use and copy whatever you want from that project
> (https://github.com/dLuna/Erlang-type-checker).
Awesome - thank you very much.

> There are a few caveats:
> 1. I have not tested this in a long time, and I'm heavily depending on
> Dialyzer for the type parsing.  If Dialyzer has been changed, my code
> might break.
Ok that's perfect - I've struggled to get my head into which parts of
Dialyzer can be reused in this way, so just having this as a head start is
really helpful!

> 2. Something changed in core erlang a few years back, so the code is
> broken as it stands today.  Should be an easy fix for someone wiling
> to learn a bit about core erlang (or wants to do some io:format
> programming).  I have marked the place of offending code.
Ok thanks - again, a good learning exercise.

> 3. Type checking using my current implementation is *slow*.  The
> reason for this is that I type convert the full argument even if only
> a minor piece is necessary. (e.g. given the type [any()] my code would
> still convert a list with a thousand deeply nested elements into its
> fully expanded type)  The fix for this is easy, but time consuming.
I'm not planning on doing real type checking anyway - just seeing whether a
specification for a function matches the -spec for any known code without
any widening conversion. For instrumentation purposes this is very easy, for
search it's a bit harder.

> Anyway.  Even if it turns out that the core erlang parts are hard to
> reuse, the code server parts should be straight forward to copy.  If
> anyone wants to know more detail just ask and I'll see what I can
> remember.
Brilliant - this should get me started playing with instrumentation and
hopefully I can glue together the code server parts along with webmachine
and a decent search index to make a hoogle-esque search service. Someone
with a visually creative mind might then be willing/able to come along and
actually make a reasonable looking front end for it then.

ps. Assume that it's under an MIT license, and I'll add the actual
> license statement later this week.
Cool. I'll most likely license the instrumentation and code-search projects
in the same way.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110927/b6bb87a1/attachment.htm>

More information about the erlang-questions mailing list