compile options+documentation consistency

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

compile options+documentation consistency

Danil Zagoskin-2
Hi!

I had a simple task: get an AST of a module (.erl) after preprocessing it (includes + parse_transforms).

This is how I first understood some options:
* 'P' — get a transformed code instead of a compiled module
* 'binary' — get a result in return value instead of a file

So, I run compile:file("example.erl", ['P', binary]) and indeed get an AST in third position of returned tuple.
Surprise: example.P file is still written on disk, and it contains Erlang code, not the returned AST.

Reading the compile.erl I found an undocumented 'to_pp' option.
Passing 'to_pp' alone also generates example.P file, but this time it contains AST.
Passing both 'to_pp' and 'binary' works as I wanted — AST in returned tuple, no files written.

My suggestions:
* make 'binary' (well, naming legacy) always switch from only writing to file to only returning result.
* associate every content with its own file extension (e.g. example.ast for AST)
* document 'to_pp' and other options

This would make using compiler in non-trivial way easier:
* choose at which pass should compiler stop
* choose where the result goes


Any thoughts on this?

--
Danil Zagoskin | [hidden email]

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: compile options+documentation consistency

Danil Zagoskin-2
One thing more (to not create extra thread)

In the documentations there are notes describing some options behaviour, e.g.
> The options {nowarn_unused_function, FAs}, {nowarn_bif_clash, FAs}, and {nowarn_deprecated_function, MFAs}
> are only recognized when given in files. They are not affected by options
> warn_unused_function, warn_bif_clash, or warn_deprecated_function.

It's hard to notice them if you read about affected options — this note is almost 2 screens below
the nowarn_deprecated_function description.

Maybe it would be easier to read the note if affected options had a link to it, e.g.

> {nowarn_deprecated_function, MFAs}
> (This option works only when given in a file and has a precedence over warn_deprecated_function option. See Note [4] for details)
> Turns off warnings for calls to deprecated functions likenowarn_deprecated_function
> does, but only for the mentioned functions. MFAs is a tuple {Module,Name,Arity} or a list of such tuples.


On Wed, Jun 6, 2018 at 1:16 PM, Danil Zagoskin <[hidden email]> wrote:
Hi!

I had a simple task: get an AST of a module (.erl) after preprocessing it (includes + parse_transforms).

This is how I first understood some options:
* 'P' — get a transformed code instead of a compiled module
* 'binary' — get a result in return value instead of a file

So, I run compile:file("example.erl", ['P', binary]) and indeed get an AST in third position of returned tuple.
Surprise: example.P file is still written on disk, and it contains Erlang code, not the returned AST.

Reading the compile.erl I found an undocumented 'to_pp' option.
Passing 'to_pp' alone also generates example.P file, but this time it contains AST.
Passing both 'to_pp' and 'binary' works as I wanted — AST in returned tuple, no files written.

My suggestions:
* make 'binary' (well, naming legacy) always switch from only writing to file to only returning result.
* associate every content with its own file extension (e.g. example.ast for AST)
* document 'to_pp' and other options

This would make using compiler in non-trivial way easier:
* choose at which pass should compiler stop
* choose where the result goes


Any thoughts on this?

--
Danil Zagoskin | [hidden email]



--
Danil Zagoskin | [hidden email]

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions