[erlang-patches] Put compile options from code into parse

Discussion:

[erlang-patches] Put compile options from code into parse_transform/2 options variable

unknown

2014-05-01 07:19:42 UTC

Put compile options from code (i.e. -compile(myoption1)) into the options
variable used as second argument in parse_transform/2. This makes it
possible to access all compile options (i.e. the ones specified in the
command-line and the ones specified in code) in a consistent way.

Here is a simple example:

(dummy_module.erl)

-module(dummy_module).

-compile({parse_transform, dummy_transform}).
-compile(dummy_transform_option1).

(dummy_transform.erl)

-module(dummy_transform).

-export([parse_transform/2]).

parse_transform(Forms, Opts) ->
true = lists:member(dummy_transform_option1, Opts),
Forms.

Links:

git fetch git://github.com/efcasado/otp.git compile-options

https://github.com/efcasado/otp/compare/erlang:maint...compile-options
https://github.com/efcasado/otp/compare/erlang:maint...compile-options.patch

https://github.com/erlang/otp/pull/350
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140501/a78579c0/attachment.html>

unknown

2014-05-01 12:51:04 UTC

Permalink

What happens if I have a module defined as:

-module(dummy_module).

-compile({parse_transform, dummy_transform1}).
-compile({parse_transform, dummy_transform2}).
-compile(dummy_transform_option).
-compile(other_dummy_transform_option).

How does that end up working?

Regards,
Fred.

Post by unknown
Put compile options from code (i.e. -compile(myoption1)) into the options
variable used as second argument in parse_transform/2. This makes it
possible to access all compile options (i.e. the ones specified in the
command-line and the ones specified in code) in a consistent way.
(dummy_module.erl)
-module(dummy_module).
-compile({parse_transform, dummy_transform}).
-compile(dummy_transform_option1).
(dummy_transform.erl)
-module(dummy_transform).
-export([parse_transform/2]).
parse_transform(Forms, Opts) ->
true = lists:member(dummy_transform_option1, Opts),
Forms.
git fetch git://github.com/efcasado/otp.git compile-options
https://github.com/efcasado/otp/compare/erlang:maint...compile-options
https://github.com/efcasado/otp/compare/erlang:maint...compile-options.patch
https://github.com/erlang/otp/pull/350
_______________________________________________
erlang-patches mailing list
erlang-patches
http://erlang.org/mailman/listinfo/erlang-patches

unknown

2014-05-01 17:47:54 UTC

Permalink

AFAIK, there is no way to specify per-transform options. So
all four compile options will end up in the "options" variable
of the two specified parse transforms. Exactly as if you had
compiled "dummy_module" as:

erlc "+{parse_transform, dummy_transform1}" "+{parse_transform,
dummy_transform2}" \
+dummy_transform_option +other_dummy_transform_option dummy_module.erl

If someone were to implement support for per-transform options,
it may be worth considering to add an (optional) third element to
the "parse_transform" compile option (i.e. {parse_transform, Module, Opts}).

Regards,
Enrique

Post by unknown
-module(dummy_module).
-compile({parse_transform, dummy_transform1}).
-compile({parse_transform, dummy_transform2}).
-compile(dummy_transform_option).
-compile(other_dummy_transform_option).
How does that end up working?
Regards,
Fred.

https://github.com/efcasado/otp/compare/erlang:maint...compile-options.patch

Post by unknown
https://github.com/erlang/otp/pull/350
_______________________________________________
erlang-patches mailing list
erlang-patches
http://erlang.org/mailman/listinfo/erlang-patches

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140501/4cdede11/attachment.html>

unknown

2014-05-01 19:40:42 UTC

Permalink

I have done a few things in this area:

When using the parse_trans transform functions, you can provide an option, either as a compile attribute in the code or added as an option to compile, to save a pretty-printed result or simply write the resulting forms to a file:

https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L397

I haven?t exported parse_trans:option_value/3, but it?s fairly simple:
https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L457

In another project, I played around with Igor for module inlining. Igor takes some options, which makes it awkward to use directly as a parse transform, so I wrote a wrapper:

https://github.com/Feuerlabs/exometer/blob/master/src/exometer_igor.erl

BR,
Ulf W

Post by unknown
AFAIK, there is no way to specify per-transform options. So
all four compile options will end up in the "options" variable
of the two specified parse transforms. Exactly as if you had
erlc "+{parse_transform, dummy_transform1}" "+{parse_transform, dummy_transform2}" \
+dummy_transform_option +other_dummy_transform_option dummy_module.erl
If someone were to implement support for per-transform options,
it may be worth considering to add an (optional) third element to
the "parse_transform" compile option (i.e. {parse_transform, Module, Opts}).
Regards,
Enrique
-module(dummy_module).
-compile({parse_transform, dummy_transform1}).
-compile({parse_transform, dummy_transform2}).
-compile(dummy_transform_option).
-compile(other_dummy_transform_option).
How does that end up working?
Regards,
Fred.

_______________________________________________
erlang-patches mailing list
erlang-patches
http://erlang.org/mailman/listinfo/erlang-patches

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140501/75d0d43b/attachment.html>

unknown

2014-05-01 20:36:46 UTC

Permalink

Thanks for sharing, Ulf.

The solution you propose in parse_trans:option_value/3 is exactly what I
ended up implementing in my project. However, IMHO, it does not feel right
that one has to scan the forms of a module in order to get hold of compile
options specified in the module being parse transformed. Specially when the
parse_transform/2 function has an "options" variable that already contains
a list of **some** compile options (including any {parse_transform, Module}
option that may have been defined in that module. This sounds a little bit
counterintuitive to me.

IMHO, the second argument of the parse_transform/2 function should contain
a list of all compile options targeting the module being parse transformed,
unless there is a good reason for not doing so.

Post by unknown
When using the parse_trans transform functions, you can provide an option,
either as a compile attribute in the code or added as an option to compile,
to save a pretty-printed result or simply write the resulting forms to a
https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L397
https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L457
In another project, I played around with Igor for module inlining. Igor
takes some options, which makes it awkward to use directly as a parse
https://github.com/Feuerlabs/exometer/blob/master/src/exometer_igor.erl
BR,
Ulf W
On 01 May 2014, at 19:47, Enrique Fern?ndez Casado <efcasado>
AFAIK, there is no way to specify per-transform options. So
all four compile options will end up in the "options" variable
of the two specified parse transforms. Exactly as if you had
erlc "+{parse_transform, dummy_transform1}" "+{parse_transform, dummy_transform2}" \
+dummy_transform_option +other_dummy_transform_option dummy_module.erl
If someone were to implement support for per-transform options,
it may be worth considering to add an (optional) third element to
the "parse_transform" compile option (i.e. {parse_transform, Module, Opts}).
Regards,
Enrique

Post by unknown
Put compile options from code (i.e. -compile(myoption1)) into the

options

Post by unknown
variable used as second argument in parse_transform/2. This makes it
possible to access all compile options (i.e. the ones specified in the
command-line and the ones specified in code) in a consistent way.
(dummy_module.erl)
-module(dummy_module).
-compile({parse_transform, dummy_transform}).
-compile(dummy_transform_option1).
(dummy_transform.erl)
-module(dummy_transform).
-export([parse_transform/2]).
parse_transform(Forms, Opts) ->
true = lists:member(dummy_transform_option1, Opts),
Forms.
git fetch git://github.com/efcasado/otp.git compile-options
https://github.com/efcasado/otp/compare/erlang:maint...compile-options

https://github.com/efcasado/otp/compare/erlang:maint...compile-options.patch

Post by unknown
https://github.com/erlang/otp/pull/350
_______________________________________________
erlang-patches mailing list
erlang-patches
http://erlang.org/mailman/listinfo/erlang-patches

_______________________________________________
erlang-patches mailing list
erlang-patches
http://erlang.org/mailman/listinfo/erlang-patches
Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140501/d9c04c81/attachment-0001.html>