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

In article <193-117860805.20040803085837@soyabean.com.au>, Gavin
Sinclair <gsinclair@soyabean.com.au> wrote:

> On Tuesday, August 3, 2004, 8:01:38 AM, Jesse wrote:
> 
> > 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.  

Yes, that was asserted and one example was offered to support it. It
may even be true that most Lisp macros can be done more or less
naturally using anonymous functions or closures. But I suspect that the
code that uses macros is more intentional. And, of course, the more
complex macros especially the domain specific ones will often be
expressed much more cleanly using macros.

> Your statement implies that Ruby blocks are
> equivalent to LISP closures, which is untrue.

As far as I can tell Lisp lambda functions (ie closures) do everything
that Ruby blocks and proc objects do but with cleaner semantics and
fewer artifical distinctions.

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

I'm not so sure, I experimented with defining FSMs in a dynamic
language with good support for anonymous functions/closures and the
macro based solution was a whole lot nicer to use.

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

Like I said it's perfectly feasible to have a decent hygienic macro
system in a language with conventional 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.

Yeah, that's one common application.

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

True, but speed is important. And in many OO languages inlined code can
do things that functions cannot. For example, in a lot of OO languages
you can't write a swap function, but a swap macro is trivial.

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

I actually come at this from a Dylan POV, not from a Lisp one and Dylan
has a conventional syntax. My concern is that most languages are
insufficiently expressive and macros seem like a great way to extend
the expressiveness of a language.

Of course this assumes a decent macro system: one where macros respect
scope, are integrated into the grammar so they don't run wild like C
macros, and are hygienic so their meaning isn't context dependant.

  -- Jesse