nimforum mirror - Term rewriting macros

Araq (orginal) [2012-09-11T00:22:49+02:00] view original

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. :D

renoX (orginal) [2012-09-11T10:43:51+02:00] view original

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

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

'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.

Araq (orginal) [2012-09-11T12:34:01+02:00] view original

It's only an example, you can easily do let tmp = f(); tmp + tmp in a template.

Fair enough, I'll change that.

adrianv (orginal) [2012-09-11T16:32:01+02:00] view original

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 ;-)

Araq (orginal) [2012-09-11T20:49:05+02:00] view original

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.

adrianv (orginal) [2012-09-12T09:02:33+02:00] view original

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.

adrianv (orginal) [2012-09-12T09:55:35+02:00] view original

sorry, I forgot that there is: from module import ....

Araq (orginal) [2012-09-12T19:37:27+02:00] view original

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. ;-)

adrianv (orginal) [2012-09-13T12:22:30+02:00] view original

great - this sounds good

Araq (orginal) [2012-11-29T00:26:14+01:00] view original

This syntax has been choosen and implemented as the star has no special meaning in from statements:



import buggymodule except optBroken, optBroken2

jibal (orginal) [2015-08-02T20:53:47+02:00] view original

This page shows up in a web search for term rewriting macros, but the link at the top is no longer valid. Here is the correct link:

http://nim-lang.org/docs/manual.html#term-rewriting-macros

Araq (orginal) [2015-09-15T02:46:36+02:00] view original

Also relevant for this topic:

http://arxiv.org/pdf/1104.1729.pdf

Henry (orginal) [2015-09-15T09:50:15+02:00] view original

VERY interesting paper, thanks for the link.

Mirror of forum.nim-lang.org

70 :: Term rewriting macros