[erlang-questions] Dialyzer type/spec info question

Robert Virding rvirding@REDACTED
Thu Nov 20 03:53:50 CET 2014


I have now push the first version of dialyzer and LFE on to github in the
lfe-dev branch. See the mailing list for more information
https://groups.google.com/forum/#!forum/lisp-flavoured-erlang.

It is possible but dialyzer is not giving up without a fight.

Robert


On 18 November 2014 11:36, Peer Stritzinger <peerst@REDACTED> wrote:

> On 2014-11-17 17:26:01 +0000, Robert Virding said:
>
>  The reason I would like to be able to handle multiple file types is to
>> simplify checking systems with parts which are written in different
>> languages.
>>
>
> +1
>
> This would be useful to my IEC61499 PLC language compiler too, especially
> since I have some native (here meaning in Erlang) implemented behaviour
> callback modules which can then be checked if they implement a matching
> interface to the PLC interface part.
>
> And since I'm also generating core like LFE opening up this interface to
> Dialyzer would help me greatly.
>
> Especially so since I'm compiling a statically typed language anyway and
> could derive the typespecs of the underlying Erlang types from this
> information.
>
> Cheers,
> -- Peer
>
>
>
>> Robert
>>
>>
>> On 17 November 2014 18:19, Robert Virding <rvirding@REDACTED> wrote:
>> Something much naughtier and more basic.
>>
>> - Make LFE local copies of the relevant dialyzer modules which have been
>> hacked to be able to handle LFE files as input (with a new --lfe option)
>> - Run dialyzer using -pa to push the local module directory first so as
>> to use these special modules instead of the standard ones
>>
>> This will make it possible to use dialyzer on LFE files and other .erl or
>> .beam files as well. Maybe with a little more hacking fix have multiple
>> file types. Of course if dialyzer was to be opened up so that it would use
>> the filename extension to pick the right versions of the functions Stavros
>> mentioned then this would be much simpler. Wink, wink, nudge nudge. :-)
>>
>> This is my plan anyway.
>>
>> Robert
>>
>> P.S. Having LFE generate erlang AST has never been an option as it is
>> very close to core and it would take a lot of effort to go back to erlang
>> which would then be undone by the erlang compiler.
>>
>>
>> On 17 November 2014 17:49, José Valim <jose.valim@REDACTED>
>> wrote:
>> Robert, what would a specialized version of dialyzer entail? A fork? A
>> specific front-end? Curious. :)
>>
>> On Monday, November 17, 2014, Robert Virding <rvirding@REDACTED> wrote:
>> Ah, so then in principle I can make my own specialised versions of the
>> dialyzer load modules which takes the core which the LFE compiler generates
>> and extracts the core and the type/spec data dialyzer needs. This without
>> any Erlang AST which LFE never generates anyway.
>>
>> Now we are getting somewhere useful. With this we don't really need to be
>> able to store core in the .beam files if we can accept using source files
>> as input.
>>
>> Robert
>>
>>
>> On 17 November 2014 17:32, Stavros Aronis <aronisstav@REDACTED> wrote:
>> For .erl files, dialyzer calls the compiler with 'to_pp', which stops the
>> compilation before code is converted to Core, and reads attributes from
>> there.
>>
>> Judging from v3_core, line 170 the two representations should be
>> compatible.
>>
>> /Stavros
>>
>> On Mon, Nov 17, 2014 at 5:11 PM, Robert Virding <rvirding@REDACTED>
>> wrote:
>> From where does it get it if I have .erl files as input? From the AST as
>> well? Do you know if there is any difference in the data itself between the
>> AST and core? I am guessing not but want to check. If there is no
>> difference then the info could be gotten from Core. This would make it
>> easier to use dialyzer together with LFE.
>>
>> Robert
>>
>>
>> On 17 November 2014 17:03, Stavros Aronis <aronisstav@REDACTED> wrote:
>> Hi Robert,
>>
>> Dialyzer gets this info from beam_lib:chunks(File, [abstract_code]) which
>> corresponds to the AST and is included in beam files if +debug_info is used
>> while compiling.
>>
>> To my knowledge there is no reason to not let sources be combined (except
>> perhaps when building a PLT), but the implementation seems to require
>> uniformity.
>>
>> Relevant functions: dialyzer_utils:get_abstract_code_from_{src,beam}/{1,2},
>> get_spec_info/3, get_record_and_type_info/1.
>>
>> Regards,
>>
>> Stavros
>>
>> On Mon, Nov 17, 2014 at 4:53 PM, Robert Virding <rvirding@REDACTED>
>> wrote:
>> From where does dialyzer get the user added type and spec info? From the
>> AST, or from Core erlang which contains the same type/spec data? And why?
>> Can I control it?
>>
>> An extra question: why doesn't dialyzer allow me to mix input from both
>> .erl and .beam files? Or does it and I have missed that?
>>
>> Robert
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> José Valim
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Lead Developer
>>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141120/eb16ba85/attachment.htm>


More information about the erlang-questions mailing list