[ruby-talk:23656] Re: Ruby macros

On Sun, 28 Oct 2001, Alexander Schofield wrote:

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

I disagree.  It would be far, far easier to write a simple S-expression
parser for Ruby than it would be to bring everything Ruby to Common Lisp,
including:

- the entire Ruby object system
- the entire Ruby library
- all available, and future, Ruby code and extensions
- the Ruby community

Since I'm not willing to give up any of the above, but would like macros,
I'm pretty certain that bringing macros to Ruby is easier than bringing
Ruby to CL.

The other issue, which I've only recently come across when playing with
Lisp, is that it's very hard to map a real message passing object model
onto generic functions.  How do you do method_missing?  And without
method_missing, how do you do, say, dRb?  Unless you use some syntax like

(send 'foo obj)

which could be wrapped in a reader macro, leading to ugly constructs like

(if [foo obj] ... ), and preventing methods from being used as a lambda
anywhere.

I would love to see multimethods (Guy Decoux used to have an
implementation of them for Ruby... whatever happened to it?), as well as
method combinators, but generic functions are not the way to do it.

> 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.
>
>
> 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.
>
>
> I have no idea how this would be implemented under the hood, or how
> difficult it would be, but from a pure OO standpoint it would be quite
> straightforward.  You could have a MultiMethod (subclass of Method) take
> the place of Method in an object whenever necessary, and choose the
> correct code to execute by examining the type of the arguments passed to
> it against the types of the specified execution branches and choose the
> most specialized one (I say execution branches because I'm not sure how
> it would be implemented, since you couldn't have the execution branches
> as attributes of the MultiMethod object, because the idea is to write
> them just like normal methods of the class, able to access all instance
> and class methods and attributes normally).
>
>
> Enough.  Opinions anyone?
>