From: Alexander Schofield Date: 2001-10-29T04:36:25+09:00 Subject: [ruby-talk:23690] Re: Ruby macros Avi Bryant wrote: > 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. Well, when you throw in the middle two I certainly agree with you, but the entire Ruby Object System wouldn't be hard (though it wouldn't be trivial, excepting interoperability with real Ruby interpreters, ie. serialization & dRb). As for the Ruby Community, I can only speak for the tiny portion of it that I represent, but I pledge not to become outraged, or make any motion to have you banned from this ML if you decided to implement it in CL. Implementing it in scheme of course is another story :). Just as an example, Paul Graham, in two of his books, On Lisp, and ANSI Common Lisp, implements a working OO system of the Generic Function Model (CLOS), and the message-passing model respectively. > 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. Yes, it's a difficulty which I suspect led Steele to come up a whole new model (GF), rather than simply adapting multi-methods to the message-passing model, and keeping methods as attributes of objects. It's difficult, but certainly not impossible. One solution that might work is to have two macros, say instantiate and instance-let, set whatever symbol you supply to a macro that would examine its args, make a determination of what method to call, so you could have something like: (instantiate audi 'Car :color 'red) and have a (instance message args...) kind of syntax: (audi setColor 'blue) because audi would actually be macro that determines what method to choose by examining its arguments. So as for method_missing it's OK, because the audi macro is able to detect an invalid method and call method_missing as expected. With this approach passing around methods belonging to a specific object as a lambda is also no problem ie. (lambda () (audi getColor)). As for dRb, that would be difficult to replicate because it deals with Ruby internals. But if you were just writing something which had to interact with other CL interpreters you could use the same approach as above, say have instantiate-remote and remote-instance-let macros which would take appropriate action, say by creating a local interface for the methods of the remote object. > 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. Maybe I wasn't clear enough. I was not implying that we take the whole GF model, just multi-methods. I wasn't even proposing it for an S-exp front to Ruby, I'd like to see it in the language proper.