On Mon, Feb 23, 2009 at 2:09 PM, Brent Roman <brent / mbari.org> wrote:
>
> Thanks for this detailed, well reasoned post.
>
> It seems, after just a few minutes reading, that you have implemented
> a separate macro preprocessor similar to the 'C' preprocessor in spirit.
> Certainly, if such a tool is implemented in Ruby it can be part of any
> project and maintained separately by that project's author.
>
> Perhaps, over time, a standard might evolve to save others the pain
> of reinventing that wheel.  ¨Âôèéó ÷èáô ùïáòáäöïãáôéîçïò áòùï> thinking that some form of macro processing would become in integral partf
> core ruby's parser?

The code example was just a toy to show what string-based macros might
look like, in contrast to the macro definitions found in the rewrite
project (described as "tortuous").

The eventual goal, if pursued, would be a real macro system with
capabilities similar to that of Lisp, not a blunt instrument like the
C preprocessor.

My toy example expands macros recursively, which already makes it very
different from a C preprocessor.  The README shows some code-expanded
literals of Fibonacci numbers

   fib(6)   >==macro==>  (((((1 + 1) + 1) + (1 + 1)) + ((1 + 1) + 1)))

The next task would be to design an unquote mechanism.  Macros are
introduced in chapter 7 of "On Lisp"
http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf

Though I understand the tendency to brush aside the idea of macros in
Ruby, in my case the issue is practical and tangible.  Without macros
there is no way to capture a lambda definition, and therefore there is
no way to define network-distributed tasks using natural syntax.

I also thought the abuse of Proc#binding was an interesting case of
twisting the language to do something it was not designed to do.
Maybe that's a sign the language should be powerful enough to do it
naturally.

To finally answer your question, I was advocating the addition of
macros, in whatever form, to the Ruby language.  If the higher-ups
say, "No, never, never, ever," then that determines the direction in
which efforts should be made.  Like my experiment, some things can be
done on top of Ruby (with major performance issues), but other things
cannot.