[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.
Cheers!
Tim
-------------- 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