6

According to the erl_id_trans documentation:

Programmers are strongly advised not to engage in parse transformations and no support is offered for problems encountered.

Why are programmers strongly advised not to use parse_transform/2? Will this not be supported in the future? Other than parse_transform/2, is there a mechanism to inject code (runtime bytecode modification) or modify the source code before it gets compiled?

Peer Stritzinger
  • 8,232
  • 2
  • 30
  • 43
justin
  • 3,357
  • 1
  • 23
  • 28

1 Answers1

9

One reason I can imagine is that they don't want to fix the syntax tree format.

So if you use Parse teansforms and they break because of a new version of Erlang you can't complain.

Addendum: in the comments arose the question about other ways to manipulate Erlang source- or byte-code

  • For semiautomatic code refactoring there is Wrangler

  • You have acces to the Erlang preprocessor, tokenizer and parser, giving e.g syntax trees of your program

  • For easy and portable manipulation of abstract forms (what you get out of the parser or even beam-files) there are syntax_tools

  • For manipulating beam-files ther is beam_lib

Seth Carnegie
  • 73,875
  • 22
  • 181
  • 249
Peer Stritzinger
  • 8,232
  • 2
  • 30
  • 43
  • Oh ok, so it was about compatibility. Thanks for answering. Do you happen to know of any other means to manipulate source/byte code? I am still looking into this, but as far as I can tell, parse_transform seems to be the way to go if someone wants to add functionality to pre-existing Erlang code. – justin Oct 22 '11 at 18:27
  • IMHO: if parse transforms just fit to your problem *and* you are sure there is no good parse-transform free wayvto do it just go ahead and use it. – Peer Stritzinger Oct 22 '11 at 21:30
  • I would say that the main problem is that the erlang abstract syntax is not trivial and it is easy to generate illegal code. One problem with using them is that you **CANNOT** create new syntax as parse transforms are applied after parsing. – rvirding Oct 23 '11 at 18:22
  • Thank you both for your feedback. @rvirding, not being able to create new syntax using parse transform doesn't seem to be a problem... more like that that's not what they're meant for. Yep I need to look at beam_lib in more detail... but having to compile with debug_info is already a bit ugly. I am looking at the options available for going about adding some basic AOP. Seems like the methods mentioned by Peer just about covers them so I'm accepting this answer. Cheers. – justin Oct 23 '11 at 20:48
  • @rvirding: yeah its a pity (and probably a blessing) that one cannot generate new syntax. No full blown Lisp macros in Erlang syntax, but then there is LFE, does it have macros? – Peer Stritzinger Oct 25 '11 at 08:07
  • @PeerStritzinger: of course LFE has real macros, it wouldn't be a lisp without them. Unfortunately as Erlang is what it is they are really only compile-time macros, but you can still do wondrous things with them. – rvirding Oct 26 '11 at 01:41