[ruby-core:22407] Re: On the consideration of macros

On Tue, Feb 24, 2009 at 12:29 AM, Yehuda Katz <[e-mail]> wrote:
> Matz has repeatedly and explicitly expressed that he did not want Ruby to
> have macros. That might have changed, but I believe he repeated it recently
> at LoneStar RubyConf. I believe Matz has argued that macros are too complex
> for the average programmer...

I have been specifically talking about a simple string-based macro
system which does not modify Ruby syntax.  It is not susceptible to
all the criticism Matz has given toward macros in general.  I should
have been more explicit about this, but my post was already too long.
From 2004:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/108143

Matz wrote on Tue, 3 Aug 2004
> * 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.

Agreed, and this is not relevant to my macro proposal.  I said both
the initial code and the substituted code must be valid Ruby syntax.
It will always look like Ruby, though some of it will look like Ruby
inside a string.

> * 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.

Agreed, and this is not my proposal.  String substitutions are easy,
yet hugely better than a C preprocessor since arbitrary code can run
before producing the final code string.  I showed an example of a
recursive macro which generates Fibonacci numbers at parse time.

> * 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.

Agreed.  But is Ruby half full or half empty?  The answer to that
question depends upon how much time you've spent on the empty side.
If the purpose of your application is to send lambdas over the wire,
or to otherwise do something which is surprisingly not possible in
Ruby, then you might change your mind.

> * 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.

Agreed.  I said that implementations should not disclose their AST.
One could optionally use a tool to parse the string (ruby_parser) in
order to step through s-exps, then use an unparser (ruby2ruby) to
generate the result string.  But those are ruby_parser's s-exps, not
hard-coded implementation-dependent s-exps.