On Tuesday, August 3, 2004, 8:01:38 AM, Jesse wrote:

> In article <126117684609.20040802210655 / scriptolutions.com>, Lothar
> Scholz <mailinglists / scriptolutions.com> wrote:

>> Hello jim,
>> 
>> >> However i think it is quite easy to emulate some form of macro
>> >> functionality in Ruby. Here is some simple code:
>> 
>> jfo> I've heard Matz say that Ruby will not support macros.
>> 
>> And i hope that he never changes his opinion at this topic.
>> 
>> jfo> They are too easily abused and can mutate the language.
>> 
>> They easily make code much more unreadable.

> Banning a feature because it can be misused is a pretty weak rationale.
> It might make sense for something like goto where you can provide more
> structured alternatives that take care of most cases, but I don't think
> macros fall into this case.

> It's been said in this thread that Ruby doesn't need macros because it
> has blocks but, this too, seems like a very weak argument. After all
> Lisp is famous for its support for closures and Lisp programmers still
> value the maro support in Lisp.

That itself is a weak argument.  Elsewhere in the thread it was
mentioned that most uses of macros in LISP are to do what Ruby does
naturally with blocks.  Your statement implies that Ruby blocks are
equivalent to LISP closures, which is untrue.

>>From what I can tell macros offer three benefits: 1) They allow you to
> extend the syntax of the language to directly support your problem
> domain. For example, if you work with finite-state machines you can
> write a macro that allows you to declaratively define FSMs.

I bet it's easy to declaritively define FSMs in Ruby.  But beyond
that, mere talk of "extending syntax" doesn't translate from LISP to
Ruby, as LISP doesn't have anything recognisable as programming
language syntax.

> 2) Macros allow you to evaluate arguments zero or more times whereas
> functions and blocks normally eagerly evaluate arguments once.

Yes, nice idea.  My very limited understanding is that this is
typically used to implement control structures commonly found in other
languages.

> 3) Macros are inlined so they may execute faster than a block.

That's just a speed issue, which Matz is addressing in other ways.

> Of these benefits, blocks only address point two and that in a rather
> clunky fashion.


>> As said before lisp is different because of the general S-Expression
>> style of this language.

> Different only in that it's easier to implement macros in Lisp. But
> more conventional languages, like Dylan, also support macros.

So it's an implementation issue.  But when the difficulty of
implementation becomes large, the rationale for doing so must become
strong.  I know that IANAL (I am being anal), but you have to
demonstrate some real benefit to Ruby, not benefit to LISP.

Cheers,
Gavin