From: Jesse Jones <jesjones@...>
Date: 2004-08-04T08:26:32+09:00
Subject: Re: Macros in Ruby

In article <1091501355.227383.29355.nullmailer@picachu.netlab.jp>,
Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

> Hi,
> 
> In message "Re: Macros in Ruby"
>     on 04/08/03, James Britt <jamesUNDERBARb@neurogami.com> writes:
> 
> |Would true macros in Ruby be more prone to abuse than they are in Lisp?
> 
>   * Lisp does not have syntax.  They only have meta syntax
>     (i.e. S-expression), Lisp macro do not change its (meta) syntax to
>     rely on (I'm ignoring reader macro here).  In comparison, Ruby
>     does have syntax but no meta syntax, so that you can easily loose
>     syntax to rely on by macros in Ruby.  You will feel like a stranger
>     when you see Ruby programs with a lot of macros.  I don't think
>     you feel same way when you see Lisp programs with macros.

I don't buy this argument at all. It's not like good Ruby programmers
would all of a sudden use macros to rewrite the Ruby grammar. Instead
they would augment the grammar with productions that make sense for
their applications.

For example, suppose you're writing a game and you have a lot of code
that selects behavior based on percentages (75% of hits are normal
blows, 20% are critical hits, and 5% kill your foe out-right for
example). Even in a language as expressive as Ruby this is a bit
awkward to write and not especially intentional. But with macros it can
be written very cleanly:

percent-case
   0.75 case
      normal_hit
   end

   0.20 case
      critical_hit
   end

   otherwise
      kill_foe
   end
end

>   * macro system more than simplest one (e.g. C preprocessor macro) is
>     VERY difficult to design and implement for languages with usual
>     syntax.  If you are curious, see Dylan's macro.

I've done this myself and I wouldn't call it very difficult. It's
certainly not trivial, but well within the capabilities of anyone who
can write a production compiler. "Extensible Language Implementation"
by Donovan Kolbly
(<http://www.cs.utexas.edu/ftp/pub/techreports/tr02-71.ps.gz>) is a
good PHD thesis on adding macros to conventional languages.

>   * about 50% of macro usage in Lisp (extending syntax a bit) can
>     accomplish using blocks in Ruby.  we don't need inlining functions
>     when we have other rooms for optimization, for example, C extensions.

I don't know Lisp well enough to know if that figure is in the
ballpark. I do find the thought of being able to extend the language to
match my problem instead of contorting my code to fit the language
compelling though.

>   * I admit disclosing abstract syntax tree to Ruby programs can open
>     new possibilities.  it's good for users at the moment, I guess.
>     but it is very bad in a long run unless I design it perfectly.
>     I'm sure I will change my mind in AST design and alas, here comes
>     another big field of incompatibility.

This is something I have been thinking about as well. One thing that
has held me back is that it requires all implementations to expose the
same AST if you want any sort of compatibility. This seems awfully icky
for any kind of complex language.

On the other hand, macros can play a role here: you can define a very
simple kernel language (lambda calculus with one or two extensions say)
and use macros to layer a more agreeable syntax on top of the kernel.
This way the AST exposed by clients is simple enough that it doesn't
overly constrain implementations.

Of course you don't absolutely need macros for this. You can instead do
these transforms within the front-end of the compiler. But macros are a
clean way to do them and offer the same power to developers.

  -- Jesse