From: Robert Feldt <feldt@...>
Date: 2001-10-28T19:33:05+09:00
Subject: [ruby-talk:23670] Re: Ruby macros

On Sun, 28 Oct 2001, Alexander Schofield wrote:

> Robert Feldt <feldt@ce.chalmers.se> wrote:
> > However, to me it seems as a potential drawback would be that you're effectively changing the programming language so that a future maintainer will have to learn your Ruby dialect before understanding whats happening. Or is this countered by the fact that the dialect is closer to the problem domain?
> 
> In ANSI CL, "changing the programming language" is *exactly* what macros
> do.  They are, "programs that write programs", or functions that allow
> controlled evaluation of their arguments.  When combined with all of
> CL's other features (let was mentioned also labels and gensyms-- in
> other words arbitrary scoping and uninterned symbols-- so even nested
> macro's will work fine, far beyond the capabilities of a mere
> preprocesser) a macro can effectively change the language, although in
> CL this is almost always taken to mean that you keep the S-expression
> syntax but just bring it closer to the problem domain.  There are small
> exceptions to even this though, many of the looping constructs in CL
> interpret a lone symbol to signify a point of execution (for ugly
> goto's, generally only used as primitives for more advanced looping
> constructs).
> 
Could you give some short examples showing the power of the CL macro
system?

> Someone mentioned an S-expression syntax for Ruby, I'd be very
> interested in that.  But if you are willing to give up the elegant Ruby
> syntax, it seems to me that it would be far easier to write a Ruby OO
> system in CL (as CL's own CLOS is, maybe you could call it the Ruby
> Object System, or ROS?) than it would be to try and force an
> S-expression syntax on Ruby.  The possibilities opened up by this would
> be fascinating, since you would get all of CL's goodies for free,
> including packages, which would effectively take the place of namespaces
> opened up on the most recent Eckel thread, to say nothing of an elegant
> macro system, which would certainly be what the majority of ROS would
> be, just like CLOS.
> 
Likewise for CLOS, could you give a short intro to what it is? My
background is imperative programming languages and then pure functional
ones but I've never used Lisp.

> As long as everyone else gets to post their own Lisp-wishlist, I have
> something that's been festering in me for a long time.  Why not take a
> portion of CLOS's multi-methods and apply it in Ruby?  Specifically, I'm
> ambivalent about auxilliary methods (before, after, and around), but
> like the part about generic functions.  For those of you who aren't Lisp
> fans, generic functions are 'functions'-- though even in CLOS 'methods',
> might be a better name-- that are made up of one or more methods whose
> parameters are 'specialized'-- or have optional type declaration.  when
> a generic function is called it examines its parameters and chooses the
> most specialized method.  This is a little like what C++ and Java call
> function and method overloading, but it is far more flexible, providing
> all (performance aside) benefits of so-called static-typing, while in
> fact being perfectly compatible with Ruby's dynamic philosophy.  For
> those who think this is somehow just static typing in disguise go ask in
> comp.lang.lisp or comp.lang.clos.  If you are a Java fan you could
> program using generic functions as if it was just static typing, but in
> fact it allows you to do much more.
> 
The upcoming Smallscript execution engine AOS (see
www.smallscript.org) support multimethods and if there'll be a Ruby
front-end to it multi-methods are a real possibility. At least as an
experimental feature.

Regards,

Robert