Forum
Thread List
Term rewriting macros 2012-09-10 22:22:49
Araq

I've finally documented term rewriting macros: http://build.nimrod-code.org/docs/trmacros.html

AFAIK Nimrod is the only programming language that combines a (now) hygienic macro system with term rewriting rules and sideeffect and alias analysis. So, yeah, I'm pretty proud of it.

Re: Term rewriting macros 2012-09-11 08:43:51
renoX

The subjet is interesting but there are things in the document which I find a bit strange

1) 'f() + f()' can be much more expensive to compute than 'f() * 2' unless the compiler do 'tmp = f(), tmp + tmp'..

2) 'echo' isn't seen as side-effecting, ok but its name doesn't tell this to the programmer debug_echo, unsafe_echo or something like that would help.

Re: Term rewriting macros 2012-09-11 10:34:01
Araq
  1. It's only an example, you can easily do let tmp = f(); tmp + tmp in a template.
  2. Fair enough, I'll change that.
Re: Term rewriting macros 2012-09-11 14:32:01
adrianv
this term rewriting looks very interesting and powerful, but somehow dangerous as well. Can the rules be exported by a module, or are they local ? I would prefer them to be local and if somebody needs them in several places, than he can include the module. In a nightmare, I see myself hunting bugs because 2*2 gets 5
Re: Term rewriting macros 2012-09-11 18:49:05
Araq

They can be exported or hidden just like other symbols with the * export marker.

Indeed, this power comes with a price as TR macros are nonlocal program transformers. However there are several ways provided to tame them: You can turn them off with --patterns:off globally or for sections of code via {.push patterns: off.}. Additionally the compiler outputs each performed transformation as a hint message and idetools --usages works for them as well.

BTW the C++ alternative to term rewriting is expression templates which are inferior in every way (IMO):

  • They can't be turned off as easily.
  • They are much more verbose.
  • They don't allow for all the optimizations that TR macros allow.
  • They break in subtle ways if aliasing is involved.

TR macros can give matrixes and bignums implemented as a library the performance of built-ins! And I haven't even mentioned all the useful things you can do with them which do change program semantics... The price you pay in WYSIWYG is well worth it.

Re: Term rewriting macros 2012-09-12 07:02:33
adrianv
I appreciate the power of TR macros and they make nimrod unique, but since they work globally on your code, I think a more fine grade control could be useful. Maybe a pragma for the import statement which switches the import for TR macros off - so you have control which TR macros you want to use and which not. {.push patterns: off} is a all or nothing solution.
Re: Term rewriting macros 2012-09-12 07:55:35
adrianv
sorry, I forgot that there is: from module import ....
Re: Term rewriting macros 2012-09-12 17:37:27
Araq

True, but blacklisting instead of whitelisting would be better:

from buggymodule import * except optBroken, optBroken2

It is generally useful and easy to implement which means on my todo now.

Re: Term rewriting macros 2012-09-13 10:22:30
adrianv
great - this sounds good
Re: Term rewriting macros 2012-11-28 23:26:14
Araq
This syntax has been choosen and implemented as the star has no special meaning in from statements:
import buggymodule except optBroken, optBroken2
Thread List