This is interesting. You can manipulate the AST in other languages of course, for example Python. However these ASTs are so difficult to handle that programmers don't really want to work with them (see point 12. on bottom of the page http://norvig.com/python-lisp.html).
I think Paul Graham wrote that any language implementing macros with Lisp-power will effectively have to introduce something that is 'as bad or worse than the parenthesis'. [1] It will be interesting to see how this will play out in Perl6.
However the example given in this article is pretty limited, so I think we can't really tell based on that. It also begs the question 'Why not use a function?', i.e. it is not a case where one needs a macro. It will be interesting to see how Perl6 handles real macro use cases where you have to do heavy AST manipulation. I think here the Lisp syntax is really showing its strengths because you don't have to think in terms of a different representation that you don't have in front of you.
The argument on the delayed execution issue is that you could just wrap crazily-expensive-computation() in a lambda/sub that is executed conditionally.
Comments
This is interesting. You can manipulate the AST in other languages of course, for example Python. However these ASTs are so difficult to handle that programmers don't really want to work with them (see point 12. on bottom of the page http://norvig.com/python-lisp.html).
I think Paul Graham wrote that any language implementing macros with Lisp-power will effectively have to introduce something that is 'as bad or worse than the parenthesis'. [1] It will be interesting to see how this will play out in Perl6.
However the example given in this article is pretty limited, so I think we can't really tell based on that. It also begs the question 'Why not use a function?', i.e. it is not a case where one needs a macro. It will be interesting to see how Perl6 handles real macro use cases where you have to do heavy AST manipulation. I think here the Lisp syntax is really showing its strengths because you don't have to think in terms of a different representation that you don't have in front of you.
[1] See text after the 1-9 list. http://www.paulgraham.com/icad.html
Edit: Better source for [1].
It also begs the question 'Why not use a function?', i.e. it is not a case where one needs a macro
The (last) example is best being a macro because it avoids running that crazily-expensive-computation() whereas a function would evaluate it.
The argument on the delayed execution issue is that you could just wrap crazily-expensive-computation() in a lambda/sub that is executed conditionally.
Indeed. However I do like the fact that Perl6 macros & functions use the same calling syntax and so are often interchangeable.