Fwd: Lisp macros
Joe Van Dyk
---------- Forwarded message ----------
From: Joe Van Dyk <joev...@gmail.com>
Date: Sep 26, 2005 6:20 PM
Subject: Lisp macros
To: ra...@lists.rubyonrails.org
So, I'm diving into a little bit of Lisp, using
http://www.gigamonkeys.com/book/ as a starting point.
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))
(defun make-comparisons-list (fields)
(loop while fields
collecting (make-comparison-expr (pop fields) (pop fields))))
(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
You could use eval + procs to do that, right?
Joe
James Britt
> 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).
James
--
http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
Devin Mullins
could provide a good example of how that might be used practically, but
it's been quite a while since I touched lisp.
Devin
Lyndon Samson
>
> 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).
Almost here with this http://rubyforge.org/projects/parsetree/ Just need to
able able to modify it and feed it back.
This http://boo.codehaus.org/Syntactic+Macros is also interesting reading.
Lyndon
Joe Van Dyk
> 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. :(
Alexey Verkhovsky
>On 9/26/05, Devin Mullins <twi...@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"
--- foo_properties_loader.rb ---
puts File.read('foo.properties')
puts
load 'foo.properties'
puts foo_question
puts foo_answer
:)
Alex
Michael Schuerig
> 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:mic...@schuerig.de The less it changes!
http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock
Joe Van Dyk
> 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.
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?
Kev Jackson
>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?
>
>
>
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.
Kev
Jim Freeze
> 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. :)
--
Jim Freeze
Joe Van Dyk
> On 9/26/05, James Britt <jam...@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.
Was he joking?
gabriele renzi
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 :)
Martin DeMello
>
> 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.
martin
Jim Freeze
> On 9/26/05, Jim Freeze <j...@freeze.org> wrote:
> > On 9/26/05, James Britt <jam...@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.
>
> Was he joking?
Judge for yourself:
--
Jim Freeze
Devin Mullins
> 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...
Help! Is there a Lisper in the house?
Devin
Ben
>
> 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?
I really like Lisp. :)
-Ben
Ben
> (much rambling snipped)
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
Edward Faulkner
> 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:
http://www.paulgraham.com/onlisptext.html
regards,
Ed
itsme213
"Lyndon Samson" <lyndon...@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?
Jim Freeze
> >
> > 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?
--
Jim Freeze
Robbie Carlton
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).
Jeff Wood
enlighten us with your feelings?
.. I for one have never minded having "too much power". It's the exercise
of responsibility that makes programming an art.
j.
On 9/27/05, Ben <benb...@gmail.com> wrote:
>
> On 9/27/05, Jim Freeze <j...@freeze.org> wrote:
> > On 9/27/05, Ben <benb...@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". :)
>
> -Ben
>
>
--
"http://ruby-lang.org -- do you ruby?"
Jeff Wood
Sean O'Halpin
> On 9/27/05, Ben <benb...@gmail.com> wrote:
> > (much rambling snipped)
>
> Alright, now I am intrigued. How much work would it be to create a
> Ruby Lisp-like parser?
You might be interested in Rouge, a (simple) Lisp interpreter in Ruby:
http://raa.ruby-lang.org/project/rouge/
Sean
Jim Freeze
> On 9/27/05, Jim Freeze <j...@freeze.org> wrote:
> > On 9/27/05, Ben <benb...@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.
IIRC, he is in the afternoon session near the front.
--
Jim Freeze
Ben
> On 9/27/05, Ben <benb...@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". :)
-Ben
Robert Klemme
I'm by no means a Lisp expert (rather beginner) but this matches my
understanding of Lisp macros pretty well. Maybe you can add to that that
a Lisp macro invocation looks exactly like a function invocation which at
the same time integrates it seamlessly into the language and makes it
harder to read / learn Lisp.
Maybe I missed something in the discussion but I still wonder what would
be gained by having Lisp macro like capabilities in Ruby (apart from the
fun that it'd certainly be for some of us)? Do we actually gain
something? Is there something that we cannot do in Ruby without this
feature and that will become utterly easy with it? Don't get me wrong, I
don't want to put this down - I'm just wondering about the benefits.
Kind regards
robert
Randy Kramer
---<other good stuff (maybe better) snipped>----
> I'm probably overreacting, but I feel patronized when I'm told I can't
> have something because it's "too easy to abuse". :)
+1
Randy Kramer
Jim Freeze
Was that +1 to overreacting or to feeling patronized? :)
Sorry, couldn't resist.
--
Jim Freeze
Bob Hutchison
On Sep 27, 2005, at 10:09 AM, Jim Freeze wrote:
> On 9/27/05, Ben <benb...@gmail.com> wrote:
>
>> On 9/27/05, Jim Freeze <j...@freeze.org> 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.
>>>
>>>
>>
>> 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 think I agree with Ben to some degree. I don't think the outcome is
a bad one, but the reason seems like a 'cop-out'. Surely there's a
better reason than that. Even a "I don't want to" or "I don't see
why" or "Ruby takes a different approach" or "No" from Matz would be
much better. Saying that it is "too dangerous" is just asking for an
argument :-)
>
> 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?
Looking at macros on a feature by feature basis isn't going to work.
Just like learning about macros by reading about what you can do with
them isn't going to work either -- at least it didn't for me. Having
macros like Common Lisp has changes the way you think about
programming and how you do it -- they certainly changes the
programmes. I really like working in both Common Lisp and Ruby. Ruby
is very very flexible and probably can address most of the individual
features/aspects of macros, but it cannot match macros as a concept
because it simply doesn't have the concept. And that is okay, let
Ruby be Ruby.
Foolishly venturing into very dangerous territory to actually address
the question... Ruby seems to be based on a few syntactic structures
and a whole bunch of method calls. Anybody can add methods to be
called, so extending Ruby's 'syntax' that way is easy. Adding new
funny syntactic structures is what macros are for. You can't do that
in Ruby. You can in lisp. So, there would be one use for macros that
I don't think Ruby can deal with right now.
Cheers,
Bob
>
>
> --
> Jim Freeze
>
>
----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>
Bill Atkins
As Paul Graham points out, the point of macros is syntactic
abstraction. If you find yourself writing similar code over and over
or find that you're using a pattern over and over, you write out a
macro and abstract away that similarity. This makes code easier to
understand and increases maintainability by reducing multiple
instances of the same concept into a single macro.
The difference is analagous to that between procedural and
object-oriented programming. It is difficult to explain to a
procedural programmer why objects are so useful ("But what use are
classes? I can just use different functions and name them
appropriately."). The case is the same with macros; they are a
different way of thinking, and provide additional power that non-Lisp
languages do not offer.
Ruby's blocks can get you a lot of what Lisp macros can, but they are
not a complete substitute. For instance, the dotimes macro Robbie
demonstrated is possible in Ruby:
The dotimes macro could be implemented (and is implemented) as
10.times do |i|
..
end
The two bits of code are functionally identical, but it's clear that
the Ruby version is jumping through more hoops than the macro version
to present a counting abstraction to the user
(dotimes (i 10)
....)
The Ruby version must contort itself to work with Ruby's block syntax,
while the macro version has no such restrictions to deal with. I am
not digging on Ruby, but just trying to point out why macros are
different. The dotimes macro can choose when and how its parameters
are evaluated. So i is not treated as a variable name simply because
dotimes does not want to treat it that way. The code passed as "..."
is not run directly, but is instead run in the way dotimes wants it to
(that is, it is executed 10 times).
Hopefully, someone can supply some really cool examples. I haven't
done enough Lisp to have any, but http://www.gigamonkeys.com/book is a
good place to start reading about cool macros.
Bill
--
Bill Atkins
Ben
> Having
> macros like Common Lisp has changes the way you think about
> programming and how you do it
Absolutely. Well said.
> because it simply doesn't have the concept. And that is okay, let
> Ruby be Ruby.
I agree wholeheartedly. I am really enjoying learning ruby, and I
am quite happy to have it instead of Lisp for many things. Just the
fact that I don't have to choose some third party tool to use the
network or regular expressions is awesome.
-Ben
Edward Faulkner
> Maybe I missed something in the discussion but I still wonder what would
> be gained by having Lisp macro like capabilities in Ruby (apart from the
> fun that it'd certainly be for some of us)? Do we actually gain
> something? Is there something that we cannot do in Ruby without this
> feature and that will become utterly easy with it?
Lisp macros are essentially a technique for metaprogramming. Ruby
already has its own metaprogramming techniques. I suspect almost
anything you can do with one you can do with the other.
But they take very different approaches. Lisp enables metaprogramming
by making the full power of the language available at compile time.
Ruby enables metaprogramming by eliminating the distinction between
compile time and run time.
(Note that Lisp can be run interpreted too. Compilation in that case
happens just before each evaluation.)
Personally, I think the Lisp way is more elegant, and it has more
opportunities for optimization. But I think it would be a mistake to
try to graft it onto Ruby. It doesn't match with Ruby's style and
philosophy.
regards,
Ed
Phil Tomson
Lyndon Samson <lyndon...@gmail.com> wrote:
>------=_Part_8710_13814260.1127785967504
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>>
>> 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).
>
>
>able able to modify it and feed it back.
>
>
Then this was this post by George Moschovitis about a year ago where he
implmented a simple macro system (more of a preprocessor, really):
http://rubyurl.com/555
Phil
Pit Capitain
>
> Ruby seems to be based on a few syntactic structures
> and a whole bunch of method calls. Anybody can add methods to be
> called, so extending Ruby's 'syntax' that way is easy. Adding new funny
> syntactic structures is what macros are for.
And as I understand it, this is exactly what Matz didn't want to happen.
> You can't do that in Ruby.
> You can in lisp. So, there would be one use for macros that I don't
> think Ruby can deal with right now.
I also think this is the main difference, though I haven't been
programming in Lisp since more than 13 years.
Regards,
Pit
Randy Kramer
> Was that +1 to overreacting or to feeling patronized? :)
> Sorry, couldn't resist.
Hmm... maybe both ;-)
Randy Kramer
Robert Klemme
> On Wed, Sep 28, 2005 at 12:26:42AM +0900, Robert Klemme wrote:
> > Maybe I missed something in the discussion but I still wonder what would
> > be gained by having Lisp macro like capabilities in Ruby (apart from the
> > fun that it'd certainly be for some of us)? Do we actually gain
> > something? Is there something that we cannot do in Ruby without this
> > feature and that will become utterly easy with it?
>
> Lisp macros are essentially a technique for metaprogramming. Ruby
> already has its own metaprogramming techniques. I suspect almost
> anything you can do with one you can do with the other.
>
> But they take very different approaches. Lisp enables metaprogramming
> by making the full power of the language available at compile time.
> Ruby enables metaprogramming by eliminating the distinction between
> compile time and run time.
>
> (Note that Lisp can be run interpreted too. Compilation in that case
> happens just before each evaluation.)
I believe early versions were actually interpreted only and you definitely
can have a Lisp interpreter that does no compilation (you wouldn't want it
for speed reasons but it's perfectly feasible). I still don't view Lisp as
a compiled language. As far as I understand the language the runtime must
contain a compiler if you want compiled code. To me this is a definite hint
that compilation is rather an optimization technique than a feature of the
language (as opposed to C etc.). Am I wrong here?
> Personally, I think the Lisp way is more elegant, and it has more
> opportunities for optimization. But I think it would be a mistake to
> try to graft it onto Ruby. It doesn't match with Ruby's style and
> philosophy.
That pretty much covers what I suspected.
Kind regards
robert
Bob Hutchison
On Sep 27, 2005, at 4:26 PM, Robert Klemme wrote:
> I believe early versions were actually interpreted only and you
> definitely can have a Lisp interpreter that does no compilation
> (you wouldn't want it for speed reasons but it's perfectly
> feasible). I still don't view Lisp as a compiled language. As far
> as I understand the language the runtime must contain a compiler if
> you want compiled code. To me this is a definite hint that
> compilation is rather an optimization technique than a feature of
> the language (as opposed to C etc.). Am I wrong here?
>
All of the major implementations, with the exception of CLISP, are
native compilers. I know many, if not all, no longer have
interpreters at all. The only time you ever need to compile at
runtime is if you call eval, load an uncompiled source file, or
change some code on the fly (e.g. in the debugger or shell).
Cheers,
bob
gabriele renzi
maybe this thread can be interesting
http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-talk/108143?108055-108481+split-mode-vertical
gabriele renzi
> 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.
I may recall wrongly, but my I remember that
- once you have lambda forms and macros you can write everything
- Common Lisp, which is what I think people think of when writing
"lisp", still has something like X special forms (with X>20)
<snip>
> Paul Graham's "On Lisp" is available online and contains several
> chapters about macros. It gives many more examples:
I think another nice text available online for lisp noobs (like me) is
"Practical Common Lisp". It is not a whole macro cookbook like Graham's
text, but it shows how macros are really a simple concept that can be
applied to simple abstractions, that stacked on over another result in
much smaller and cleaner code
Bob Hutchison
On Sep 27, 2005, at 10:09 AM, Jim Freeze wrote:
> What exacly 'macro like' feature are you looking for?
Coincidentally, in the thread "Is there an issue with a library
extending Object" I've just described another place where lisp macros
would come in handy. The thread isn't very long so it is probably
best to read about it there.
Cheers,
Bob
Devin Mullins
> Edward Faulkner <e...@alum.mit.edu> wrote:
>
>> Personally, I think the Lisp way is more elegant, and it has more
>> opportunities for optimization. But I think it would be a mistake to
>> try to graft it onto Ruby. It doesn't match with Ruby's style and
>> philosophy.
>
> That pretty much covers what I suspected.
What I'd love to see (and I'm not asking for it, because that would be
hubris, but I would be incredibly grateful for any answers) is some
responses by Lispers saying "This-here code sample shows a technique
I've used a lot in Lisp. It's useful for (reducing duplication /
exposing simpler APIs / making coffee in the morning). When I'm in Ruby,
I really miss the ability to use it."
I agree with Edward, but that doesn't mean Ruby's maxed out,
conceptually. We might be able to discover a *different* solution to the
same problem.
Really, though, I'm just being lazy, where in good conscience I should
just learn Lisp thoroughly and figure this out for myself. So,
considering On Lisp and Practical Common Lisp have each been linked to
at least twice in this thread, I won't take offense if nobody posts
code. (Mind you, I'm not the OP.)
Devin
Robert Klemme
> On Sep 27, 2005, at 4:26 PM, Robert Klemme wrote:
>
>> I believe early versions were actually interpreted only and you
>> definitely can have a Lisp interpreter that does no compilation
>> (you wouldn't want it for speed reasons but it's perfectly
>> feasible). I still don't view Lisp as a compiled language. As far
>> as I understand the language the runtime must contain a compiler if
>> you want compiled code. To me this is a definite hint that
>> compilation is rather an optimization technique than a feature of
>> the language (as opposed to C etc.). Am I wrong here?
>>
>
> All of the major implementations, with the exception of CLISP, are
> native compilers. I know many, if not all, no longer have
> interpreters at all. The only time you ever need to compile at
> runtime is if you call eval, load an uncompiled source file, or
> change some code on the fly (e.g. in the debugger or shell).
True, but that doesn't contradict what I said, does it? I mean, you can't
have Lisp without eval - at least without it a major part would be missing.
Or do I have a misconception of Lisp here?
Kind regards
robert
Bob Hutchison
First, I wasn't trying to contradict you, just clarify the situation
a bit.
Second, I think you may have a misconception of lisp. I'm working
currently working on a lisp program that is about 10,000 lines of
code without a single eval in it. I've never come across a need for
it. No matter, eval in LispWorks, for example, compiles things, it
doesn't interpret them. I suppose I should ask: in what way is
compilation ever not an optimisation? and, in those cases, why don't
you think they apply to lisp?
Cheers,
Bob
>
> Kind regards
>
> robert
Robert Klemme
> First, I wasn't trying to contradict you, just clarify the situation
> a bit.
Ah! Ok, then I probably misread you. I'm sorry.
> Second, I think you may have a misconception of lisp. I'm working
> currently working on a lisp program that is about 10,000 lines of
> code without a single eval in it. I've never come across a need for
> it. No matter, eval in LispWorks, for example, compiles things, it
> doesn't interpret them. I suppose I should ask: in what way is
> compilation ever not an optimisation?
Good question. Of course one could interpret every compiled language -
but not necessarily the other way round. Duh!
> and, in those cases, why don't
> you think they apply to lisp?
Well, I think my point focused around the fact whether a language allows
for code modification at runtime (regardless of whether you use it or not;
I'm rather trying to grasp the nature of the language if you will). You
can do that with Lisp and as far as I understood it's a core feature of
the language. You can't do that with standard C (well, you *can* but that
typically involves features not part of the language like shared objects).
(A funny consequence seems to be that you can view machine code as a
dynamic language...)
Kind regards
robert
Bob Hutchison
On Sep 29, 2005, at 3:46 AM, Robert Klemme wrote:
> Well, I think my point focused around the fact whether a language
> allows
> for code modification at runtime (regardless of whether you use it
> or not;
> I'm rather trying to grasp the nature of the language if you
> will). You
> can do that with Lisp and as far as I understood it's a core
> feature of
> the language. You can't do that with standard C (well, you *can*
> but that
> typically involves features not part of the language like shared
> objects).
You are right about run-time changes to lisp being an important
capability. The fun thing is that you don't actually need to eval or
compile anything inside the program being modified. You have to
compile for sure, but that can be done outside by the developer then
loaded into the running image -- no eval happens. There are also very
interesting things you can do with returning functions from functions
that don't require eval (this can be a bit astonishing the first time
you see it, and every now and again after the first time :-) Here is
a quick example:
(defun make-a-function (n)
(lambda (m) (* n m)))
is returning a compiled run-time generated function (with no eval,
not even a hidden one :-)
>
> (A funny consequence seems to be that you can view machine code as a
> dynamic language...)
Very dynamic. Every now and again when I was working in assembler (a
while ago now :-) we made use of that (in fact, one computer I worked
on had instructions built into it that explicitly supported changing
the code). These days machine code as a dynamic language comes up
every now and again as a 'buffer overrun attack' :-)
Robert Klemme
Yeah, that's right. Same for Ruby. No compilation needed for closures.
>> (A funny consequence seems to be that you can view machine code as a
>> dynamic language...)
>
> Very dynamic. Every now and again when I was working in assembler (a
> while ago now :-)
I remember doing Z80 assember - wow, this was *long* ago!
> we made use of that (in fact, one computer I worked
> on had instructions built into it that explicitly supported changing
> the code). These days machine code as a dynamic language comes up
> every now and again as a 'buffer overrun attack' :-)
LOL - how true!
Thanks for the discussion!
Kind regards
robert