5 ms·
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
by paulkoer 15y ago
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 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 http://www.paulgraham.com/icad.html
Edit: Better source for [1].
- draegtun 15y agoIt 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.
- Xurinos 15y agoThe argument on the delayed execution issue is that you could just wrap crazily-expensive-computation() in a lambda/sub that is executed conditionally.
- draegtun 15y agoIndeed. However I do like the fact that Perl6 macros & functions use the same calling syntax and so are often interchangeable.