[erlang-questions] Types and Specs support in erl_syntax or erl_prettypr

[Ulf Wiger]

Here is how it's done in parse_trans_pp.erl (http://github.com/uwiger/parse_trans)

pp_beam_to_str(F) ->
    case beam_lib:chunks(F, [abstract_code]) of
        {ok, {_, [{abstract_code,{_,AC0}}]}} ->
            AC = epp:restore_typed_record_fields(AC0),
            {ok, lists:flatten(
                   io_lib:fwrite("~s~n", [lists:flatten(
                                            [erl_pp:form(Form) ||
                                                Form <- AC])])
                  )};
        Other ->
            {error, Other}
    end.

BR,
Ulf W


On 1 Mar 2012, at 22:17, Stavros Aronis wrote:

> Hi Jason,
> 
> The lack of support for types in erl_syntax is something that has bothered me as well and I think that I ran into the same issue with the erlang parser when I was trying to do some work there. If this is indeed the case, there should definitely be a way to make the representation of types in the abstract syntax better and uniform (for the records case).
> 
> Keep in mind however that at least two tools (Dialyzer and EDoc) have been designed to use the current representation, so any change will need to be compatible with those. I can definitely help with the Dialyzer front.
> 
> Regards,
> Stavros
> 
> On Thursday, March 1, 2012 3:06:24 PM UTC+1, Jason Rogers wrote:
> I've noticed a lack of support for types and specs in erl_syntax or
> erl_prettypr.
> If you try:
> 
> {ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(Beam,[abstract_code]).
> io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).
> 
> on a beam file with type or spec declarations, the resulting code will
> not compile.
> 
> Any idea if official support is forthcoming?
> 
> I tried to modify both libraries to provide some minimal support for
> my own use, but ran into an issue with typed records. A typed record
> shows up in the syntax tree twice: as a un-typed record and as a typed
> record. And the typed version, which includes all the information
> contained in the un-typed declaration, appears after the un-typed
> declaration.
> 
> So if you write code to process the typed version, you will end up
> with source code that has both a typed and an un-typed declaration.
> 
> Is there anyway to get to a single record declaration?
> 
> Thanks,
> Jason
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Thursday, March 1, 2012 3:06:24 PM UTC+1, Jason Rogers wrote:
> I've noticed a lack of support for types and specs in erl_syntax or
> erl_prettypr.
> If you try:
> 
> {ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(Beam,[abstract_code]).
> io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).
> 
> on a beam file with type or spec declarations, the resulting code will
> not compile.
> 
> Any idea if official support is forthcoming?
> 
> I tried to modify both libraries to provide some minimal support for
> my own use, but ran into an issue with typed records. A typed record
> shows up in the syntax tree twice: as a un-typed record and as a typed
> record. And the typed version, which includes all the information
> contained in the un-typed declaration, appears after the un-typed
> declaration.
> 
> So if you write code to process the typed version, you will end up
> with source code that has both a typed and an un-typed declaration.
> 
> Is there anyway to get to a single record declaration?
> 
> Thanks,
> Jason
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20120301/4955c63f/attachment.htm>