In article <41103008.7030107 / path.berkeley.edu>, Joel VanderWerf
<vjoel / PATH.Berkeley.EDU> wrote:

> Jesse Jones wrote:
> >>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.
> 
> What are some of the differences? I've been away from lisp for a while....

Between Ruby and Lisp? To tell the truth I'm not entirely sure. The
pickaxe book does a lousy job explaining the differences between blocks
and proc objects. I'm still not sure why Ruby needs two concepts when
Lisp and other languages get by with one. I also don't know why Ruby
uses that weird yield syntax.

> > 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.
> 
> I've found ruby blocks to be fairly good for defining declarative 
> constructs. For example, I based the syntax for a declarative language 
> for hybrid automata (~ FSMs + ODEs) on this technique. Here's a sample:

Very nice Joel. Macro's wouldn't seem to be a huge improvement except
that you could inline code instead of turning everything into blocks.

> Hm? Blocks can be used to defer evaluation, using the &block or Proc.new 
> constructs. Or do you mean something else?

I meant just what I said: that macros allow you to control the order of
evaluation of expressions. Although you're probably right that I should
have pointed out that blocks allow you to do the same.

  -- Jesse