Ok, I dont diasgree with your general points here. And I wasnt using VB as an example of good macro system. Just pointing out that it isn't a indication that a language is FSP. :-)

Fair enough, but the FSP/LFM article was specifically discussing macros of a Lispish variety ;-)

One issue I have however is that I dont think many people would consider parse tree access a necessary feature of a macro langauge.

Depends on your background. If you use C/C++/C/etc. a macro is something like CPP. If you use Lisp/Scheme/etc. it means a transformation of the parse tree. Lisp has had macros since the mid-sixties so for many people who were around back then, or have spent time using similar languages, that's what a programming language macro is all about.

Of course, if your an Outlook user a macro just means mailing everybody you know a virus :-)

My point here is that the use of macros for language extension is indiciative that the language is missing needed features at an integrated level.

Not always. There are always domain specific language extensions. These, by their very nature, are niche so should not be built into the core language.

There is also the problem all language implementors have - the lack of 20/20 foresight. You can't tell what the next great programming paradigm is going to be - so it's a good idea to build in a generic mechanism so people can add them in at a later date.

For example: When Lisp (back in the late fifties) and Pop-11 (back in the early eighties) were created object-oriented programming wasn't the cool thing on the block it is now.

Because both of these languages are capable of redefining language syntax and semantics they both could create complete OO systems (CLOS and ObjectClass amongst others) without having to go back to the drawing board.

Imagine how different it would have been if in Perl4 you could have added objects by doing use Perl::Objects. That's what Lisp and Pop-11 developers could do.

At the moment there are new (meaning that they have been around for years and people are finally taking notice of them) things like Aspect Oriented Programming, Design by Contract, Constraint Based Programming, etc. appearing on the horizon.

I want to be using a language that can take these new ideas and steal all of the best bits without having to re-write everything from scratch. That's what a good macro system gives you. You have a language infrastructure that you can extend to your hearts content.

I think also that in general that macros arent used for language extension. I think more often than not they are used for inlining and conditional compilation. Consider Aristotle made some points about Assert(). This example however is only a combination of inlining and conditional compilation, and as far as a source filter goes wouldnt be that hard to write (with a few minor constraints).

Minor constraints are annoying or worse. As soon as you start reducing the expressiveness of a language to make implementation easier you're on a slippery slope.

There is also the problem of that multiple source filters don't play well together.

While I personally think that providing a general extend the language mechanism with macro like features to be a powerful approach, I can only wonder what the result will be. For instance with(). I think that because LW for some reason doesnt like it (no doubt for good reasons), we will end up with a number of modules providing it with slightly different syntax. Likewise for other features the language is missing. Eventually we could find that this langauge extension facility actually undermines the cohesion of the overall codebase.

The community tends to find the good. In the same way Perl coders focused on DBI for database connectivity, Lisp coders focused on CLOS for writing OO code.

I'm sure that there will be some features that get implemented multiple time. Just like there seem to be more templating modules than PAUSE ids on CPAN. The community will quickly find the ones that give them value and give the others short shrift.

This is the thing that takes a little getting used to. A new piece of syntax is no longer a "big thing". You don't have to go and learn lots of deep magic so you can rebuild your compiler from scratch. You just load some code.

I look forward to seeing what happens.

Me too :-)