Lisp's big selling point is macros, right? I'm only up to chapter 3, but from that (maybe very basic?) display of macros, it looks like something that can be done in Ruby.
<excerpt> (defun make-comparison-expr (field value) `(equal (getf cd ,field) ,value))
(defmacro where (&rest clauses) `#'(lambda (cd) (and ,@(make-comparisons-list clauses))))
CL-USER> (macroexpand-1 '(where :title "Give Us a Break" :ripped t)) #'(LAMBDA (CD) (AND (EQUAL (GETF CD :TITLE) "Give Us a Break") (EQUAL (GETF CD :RIPPED) T))) T
Joe Van Dyk wrote: > Whoops, this belongs on ruby-talk... Sorry.
I trust the accidental exposure to Lisp wasn't too traumatizing.
Anyway, there have been sporadic discussions both here and on ruby-core about adding true Lisp-style macros to Ruby. My understanding is that while Ruby can do assorted flips and twists, it cannot do quite the same sort of things as found in Lisp (and I hope a true Lisper here can elaborate on this); I also believe that Matz is less than enamored with idea of adding this to Ruby (and I hope a true Matz can elaborate on this, too).
The big thing Lisp has that Ruby can't do is code-as-data. I wish I could provide a good example of how that might be used practically, but it's been quite a while since I touched lisp.
>Lisp's big selling point is macros, right? I'm only up to chapter 3, >but from that (maybe very basic?) display of macros, it looks like >something that can be done in Ruby.
>(defmacro where (&rest clauses) > `#'(lambda (cd) (and ,@(make-comparisons-list clauses))))
>CL-USER> (macroexpand-1 '(where :title "Give Us a Break" :ripped t)) >#'(LAMBDA (CD) > (AND (EQUAL (GETF CD :TITLE) "Give Us a Break") > (EQUAL (GETF CD :RIPPED) T))) >T
On 9/27/05, James Britt <jame...@neurogami.com> wrote:
> Joe Van Dyk wrote: > > Whoops, this belongs on ruby-talk... Sorry.
> I trust the accidental exposure to Lisp wasn't too traumatizing.
> Anyway, there have been sporadic discussions both here and on ruby-core > about adding true Lisp-style macros to Ruby. My understanding is that > while Ruby can do assorted flips and twists, it cannot do quite the same > sort of things as found in Lisp (and I hope a true Lisper here can > elaborate on this); I also believe that Matz is less than enamored with > idea of adding this to Ruby (and I hope a true Matz can elaborate on > this, too).
On 9/26/05, James Britt <jame...@neurogami.com> wrote:
> Joe Van Dyk wrote: > > Whoops, this belongs on ruby-talk... Sorry.
> I trust the accidental exposure to Lisp wasn't too traumatizing.
> Anyway, there have been sporadic discussions both here and on ruby-core > about adding true Lisp-style macros to Ruby. My understanding is that > while Ruby can do assorted flips and twists, it cannot do quite the same > sort of things as found in Lisp (and I hope a true Lisper here can > elaborate on this); I also believe that Matz is less than enamored with > idea of adding this to Ruby (and I hope a true Matz can elaborate on > this, too).
I'm just repeating what I've heard numerous times, but apparently, you can only get Lisp macros if the language has lots of silly irritating parenthesis. And since Ruby has syntax, it wouldn't be possible.
Or something. Don't pay attention to me. I have no clue what i'm talking about. :(
Joe Van Dyk wrote: >On 9/26/05, Devin Mullins <twif...@comcast.net> wrote:
>>The big thing Lisp has that Ruby can't do is code-as-data. I wish I >>could provide a good example of how that might be used practically, but >>it's been quite a while since I touched lisp.
>If anyone wants to chime in with an example of what code-as-data is or >how it could be used, I'd appreciate it!
--- foo.properties --- foo_name = 'MyFoo', foo_description = 'A code-as-data foo' foo_question = 'Why is this useful?' foo_answer = "Ah, well, sometimes it is"
James Britt wrote: > Joe Van Dyk wrote: >> Whoops, this belongs on ruby-talk... Sorry.
> I trust the accidental exposure to Lisp wasn't too traumatizing.
> Anyway, there have been sporadic discussions both here and on > ruby-core > about adding true Lisp-style macros to Ruby. My understanding is that > while Ruby can do assorted flips and twists, it cannot do quite the > same sort of things as found in Lisp (and I hope a true Lisper here > can elaborate on this); I also believe that Matz is less than enamored > with idea of adding this to Ruby (and I hope a true Matz can elaborate > on this, too).
I'm neither a true Matz nor a true Lisper. The basic facility Lisp macros offer over what is available in Ruby is that they do *not* evaluate their arguments. Where this is not an issue, you can get very far with what is there in Ruby.
Michael
-- Michael Schuerig The more it stays the same, mailto:mich...@schuerig.de The less it changes! http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock
> > Joe Van Dyk wrote: > >> Whoops, this belongs on ruby-talk... Sorry.
> > I trust the accidental exposure to Lisp wasn't too traumatizing.
> > Anyway, there have been sporadic discussions both here and on > > ruby-core > > about adding true Lisp-style macros to Ruby. My understanding is that > > while Ruby can do assorted flips and twists, it cannot do quite the > > same sort of things as found in Lisp (and I hope a true Lisper here > > can elaborate on this); I also believe that Matz is less than enamored > > with idea of adding this to Ruby (and I hope a true Matz can elaborate > > on this, too).
> I'm neither a true Matz nor a true Lisper. The basic facility Lisp > macros offer over what is available in Ruby is that they do *not* > evaluate their arguments. Where this is not an issue, you can get very > far with what is there in Ruby.
Thank you!
Does Lisp have any other advantages over Ruby that I should be looking for? When would I want to use Lisp over Ruby?
>Does Lisp have any other advantages over Ruby that I should be looking >for? When would I want to use Lisp over Ruby?
When you want to write your own language, Lisp is very useful, I'm sure that you can do this quite well with ruby (but I'm no ruby expert), but Lisp is teh poster child for domain specific languages.
On 9/26/05, James Britt <jame...@neurogami.com> wrote:
> Joe Van Dyk wrote:
> Anyway, there have been sporadic discussions both here and on ruby-core > about adding true Lisp-style macros to Ruby. My understanding is that > while Ruby can do assorted flips and twists, it cannot do quite the same > sort of things as found in Lisp (and I hope a true Lisper here can > elaborate on this); I also believe that Matz is less than enamored with > idea of adding this to Ruby (and I hope a true Matz can elaborate on > this, too).
Matz has said (at the Lightweight Language Conf) that Ruby will never have macros because they are too easily abused, by the average person, to mutate the language.
Yes, Ruby has continuations and one can abuse them, but you have to be really smart. The average person won't even use them, let alone abuse them. :)
> On 9/26/05, James Britt <jame...@neurogami.com> wrote: > > Joe Van Dyk wrote:
> > Anyway, there have been sporadic discussions both here and on ruby-core > > about adding true Lisp-style macros to Ruby. My understanding is that > > while Ruby can do assorted flips and twists, it cannot do quite the same > > sort of things as found in Lisp (and I hope a true Lisper here can > > elaborate on this); I also believe that Matz is less than enamored with > > idea of adding this to Ruby (and I hope a true Matz can elaborate on > > this, too).
> Matz has said (at the Lightweight Language Conf) that Ruby will never > have macros because they are too easily abused, by the average person, > to mutate the language.
> Yes, Ruby has continuations and one can abuse them, but you have to > be really smart. The average person won't even use them, let alone > abuse them. :)
> On 9/26/05, James Britt <jame...@neurogami.com> wrote:
>>Joe Van Dyk wrote:
>>>Whoops, this belongs on ruby-talk... Sorry.
>>I trust the accidental exposure to Lisp wasn't too traumatizing.
>>Anyway, there have been sporadic discussions both here and on ruby-core >>about adding true Lisp-style macros to Ruby. My understanding is that >>while Ruby can do assorted flips and twists, it cannot do quite the same >>sort of things as found in Lisp (and I hope a true Lisper here can >>elaborate on this); I also believe that Matz is less than enamored with >>idea of adding this to Ruby (and I hope a true Matz can elaborate on >>this, too).
> I'm just repeating what I've heard numerous times, but apparently, you > can only get Lisp macros if the language has lots of silly irritating > parenthesis. And since Ruby has syntax, it wouldn't be possible.
well you can get lisp macros only in a s-exp based language, but there are other mcro systems :) Take a look at Dylan (close relative of lisp with more syntax), Nemerle and Logix. All succed to put a powerful macro system in a syntax which does not need prefix based everything :)
> I'm just repeating what I've heard numerous times, but apparently, you > can only get Lisp macros if the language has lots of silly irritating > parenthesis. And since Ruby has syntax, it wouldn't be possible.
> Or something. Don't pay attention to me. I have no clue what i'm > talking about. :(
No, all you need is a way to manipulate the abstract syntax tree from code (or, indeed, the bytecode representation from code, for languages that work that way). Lisp gets it for free because s expressions *are* an abstract syntax tree.
On 9/27/05, Joe Van Dyk <joevan...@gmail.com> wrote:
> On 9/26/05, Jim Freeze <j...@freeze.org> wrote: > > On 9/26/05, James Britt <jame...@neurogami.com> wrote: > > > Joe Van Dyk wrote:
> > Matz has said (at the Lightweight Language Conf) that Ruby will never > > have macros because they are too easily abused, by the average person, > > to mutate the language.
Devin Mullins wrote: > The big thing Lisp has that Ruby can't do is code-as-data. I wish I > could provide a good example of how that might be used practically, > but it's been quite a while since I touched lisp.
> Devin
Well, nobody's provided an example. The best I can do is provide more explanation. Since code is just (blah blah (blah blah)) -- that is, just a list -- and Lisp has the capability to delay evaluation (I think with an '), you can pass code into another function and have that function actually manipulate the internals of your code, and build some new code out of it. You could, maybe, write something that stripped all the print statements out at runtime... Crappy example...
> Matz has said (at the Lightweight Language Conf) that Ruby will never > have macros because they are too easily abused, by the average person, > to mutate the language.
This is a cop-out. Every time a new language comes around and doesn't support some feature, the reason is always "too easily abused". Macros in lisp are about abstraction. Like every other abstraction - interfaces, classes, pointers, etc, they can be abused horribly. They can also be a powerful tool. If I recall my CS 101, computer programming is built on the pillars of algorithms and data structures. Lisp and its variants are neat because they represent the code as a native data structure. With that in place it becomes easy to create algorithms to manipulate the data structure, changing the syntax as you write, and the code as it runs. If you're familiar with the more complex metaprogramming techniques C++ provides with templates, you'll start to get the idea of what lisp macros offer you. Macros are less limiting than C++ templates though, and more naturally represented.
Consider an array in Ruby whose first element is a method call: a = [method, param1, param2] eval "${a[0]} ${a[1]} ${a[2]}" If param1 becomes an array, that is a nested call: a = [method, [method2, x, y], param2]
In Lisp, if 'method' is a macro: a = [macro, [method2, x, y], param2] then macro gets 'expanded' at compile time WITHOUT evaluating the parameters: a = [method [do-crazy-thing param2 [do-cool-thing [method2, x, y] ] ] [ [param2 method2, x, y] ] ] ; Did I match all my braces?
Alright, now I am intrigued. How much work would it be to create a Ruby Lisp-like parser?
class Risp def Risp.eval(code) # code should be an array! # What happens here? We need to create a string to be eval'ed. As # the string is created, if we find an array jump in to eval that first
On Tue, Sep 27, 2005 at 09:21:07PM +0900, Devin Mullins wrote: > Crappy example...
> Help! Is there a Lisper in the house?
Part of the attraction of Lisp macros is that they allow you to keep the core language very small, and add the features you want with macros. For example, as long as you have the lambda operator, you can define things like "while" and "let" as macros, not keywords. This is in fact how many Lisp implementations work, because it keeps the compiler/interpreter simple.
Another use for macros is to perform some of your computation at compile time, saving you from ever needing to perform it again at runtime.
In the general case, macros can be used to rewrite whole programs. For example, even though Lisp doesn't natively support continuations, you can build them with macros that rewrite your program into an explicit continuation-passing style.
Paul Graham's "On Lisp" is available online and contains several chapters about macros. It gives many more examples:
"Lyndon Samson" <lyndon.sam...@gmail.com> wrote in message > Almost here with this http://rubyforge.org/projects/parsetree/ Just need > to able able to modify it and feed it back.
Will parsetree (and Rubyinline) run on Windows, and is a precompiled version available?
> > Matz has said (at the Lightweight Language Conf) that Ruby will never > > have macros because they are too easily abused, by the average person, > > to mutate the language.
> This is a cop-out. Every time a new language comes around and
Hmm, that is strong language. Do you think Matz has made a bad decision here? Ruby does have lambda's. If you really need a lisp like language, there is always Lisp. :)
Seriously, can you put your statement in words that define exactly what you mean? What exacly 'macro like' feature are you looking for? Are you really looking for macro capability or just a lazy eval?
code as data is what makes lisp macros so powerful.
In a c macro you have the power of a little macro language to manipulate strings, in a lisp macro you have the power of lisp language to manipulate lisp data structures. I'll elaborate.
When the compiler sees a call to a macro it passes all of the arguments to the macro, before evaluating. so in a call like
(dotimes (i 10) (do-some-crazy-thing) (print i))
the macro dotimes is passed the list (i 10) and the list ((do-some-crazy-thing) (print i)) the macro can then operate on them as data, using the full power of lisp. At the end of all this, the macro returns another piece of data, a list, which is then interpreted as a lisp form, code, and evaluated.
If lisp code wasn't the same as lisp data, macros would be a lot less powerful as you would have to have two languages, one for manipulating lisp data, and another for manipulating lisp code (this is what you get in c).
Hope this helps. Sorry the example isn't very enlightening, it's difficult to illustrate the power of macros in (< 500 words) as they're very complicated. If you'd like to know more* ... learn lisp :)
Now I will stop with the lisp advocacy.
*on lisp by Paul Graham is the bible on macros, but it's a little hard for someone who's new to lisp, try practical common lisp by Peter Siebel, (both are available free online).
On 9/27/05, Devin Mullins <twif...@comcast.net> wrote:
> > The big thing Lisp has that Ruby can't do is code-as-data. I wish I > > could provide a good example of how that might be used practically, > > but it's been quite a while since I touched lisp.
> > Devin
> Well, nobody's provided an example. The best I can do is provide more > explanation. Since code is just (blah blah (blah blah)) -- that is, just > a list -- and Lisp has the capability to delay evaluation (I think with > an '), you can pass code into another function and have that function > actually manipulate the internals of your code, and build some new code > out of it. You could, maybe, write something that stripped all the print > statements out at runtime... Crappy example...
> On 9/27/05, Jim Freeze <j...@freeze.org> wrote: > > On 9/27/05, Ben <benbe...@gmail.com> wrote:
> > > This is a cop-out. Every time a new language comes around and
> > Hmm, that is strong language. Do you think Matz has made a bad decision > > here? Ruby does have lambda's. If you really need a lisp like language, > > there is always Lisp. :)
> I'm not meaning to be insulting, but saying that something is too > dangerous to put in the hands of the uneducated is almost always a way > of evading a question rather than answering it. How about: > "The goals I am pursuing with Ruby (list goals) will not be achieved > any better with macros" > "The syntax and language structure I like for Ruby will not support > macros in an intuitive, maintainable way" (I certainly agree with > this) > "I don't believe the benefits of macros are worth the effort of > supporting them in the interpreter and training developers to use > them."
> If the reason is really that they are too scary, say why: > "The delayed evaluation necessary to support macros runs contrary to > the rest of the language. This lack of clarity will prove a hindrance > to the quick development I intended Ruby to support. Also, exporting > to the client of a class those implementation details (method or > macro) violates encapsulation which will increase the learning curve > of the language."
> I'm probably overreacting, but I feel patronized when I'm told I can't > have something because it's "too easy to abuse". :)
> On 9/27/05, Jim Freeze <j...@freeze.org> wrote: > > On 9/27/05, Ben <benbe...@gmail.com> wrote: > I'm probably overreacting, but I feel patronized when I'm told I can't > have something because it's "too easy to abuse". :)
Well, it goes without saying that I am not Matz and that I am only giving my version of what Matz said at the LLC. I encourage you to watch the video and give us your opinion.
> > This is a cop-out. Every time a new language comes around and
> Hmm, that is strong language. Do you think Matz has made a bad decision > here? Ruby does have lambda's. If you really need a lisp like language, > there is always Lisp. :)
I'm not meaning to be insulting, but saying that something is too dangerous to put in the hands of the uneducated is almost always a way of evading a question rather than answering it. How about: "The goals I am pursuing with Ruby (list goals) will not be achieved any better with macros" "The syntax and language structure I like for Ruby will not support macros in an intuitive, maintainable way" (I certainly agree with this) "I don't believe the benefits of macros are worth the effort of supporting them in the interpreter and training developers to use them."
If the reason is really that they are too scary, say why: "The delayed evaluation necessary to support macros runs contrary to the rest of the language. This lack of clarity will prove a hindrance to the quick development I intended Ruby to support. Also, exporting to the client of a class those implementation details (method or macro) violates encapsulation which will increase the learning curve of the language."
I'm probably overreacting, but I feel patronized when I'm told I can't have something because it's "too easy to abuse". :)
