[EMAIL PROTECTED] writes: > What is the reason modern scripting languages have rejected macros?
Part of the reason is that these languages lack the simple syntax of Lisp, and lack the parity between surface syntax and the AST that makes writing macros not only possible, but possible without adding yet another language into the mix. Lisp macros are written in Lisp; they receive Lisp as input and emit Lisp as output. At macroexpansion time -- when the macro code runs to transform other code fed to it -- the code being operated on is just data; it doesn't "become code" again until it's time for it to run -- perhaps as a macro itself, or as "normal" code to be evaluated. > *When* do you find heavy needs for these features? The interactivity is a facet in a whole different category, but any of these features can be useful in any program. Try turning the question around: When do you know that you wouldn't use any of those features? Why decide a priori that you'd rather not have them available? > And, could that functionality by handled by something else in modern > scripting langs? The interactive idea is spreading, though I have yet to see it provided as convincingly as any (Common) Lisp system I've used. Surely these "modern" scripting languages are borrowing heavily from Lisp. The problem, though, as Paul Graham and many others writing on comp.lang.lisp have explained, is that one can never borrow enough from Lisp without becoming Lisp. The crucial aspects that make it unique are interrelated and somewhat interdependent. -- Steven E. Harris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
