Macros in Lisp
Doug Tolton
Python. Somehow, we got onto the topic of Macros. Personally I
really like Macros, so I was defending the idea of Macros in Python.
However a large group of people are diametrically opposed to Macros.
Their logic goes something like this:
1. Macros are useful
2. Macros in Python would be useful
3. Macros in Python would be used a lot
4. Using Macros in Python would splinter the community and destroy
Python.
So I thought I'd pose the question here. Do you think Macros have
destroyed the Lisp community? Were Macros responsible for offspring
languages such as Scheme? If Macro's weren't allowed into Lisp would
Lisp be a stronger more vibrant community? Without Macros would Lisp
be as powerful (ie, can you accomplish the same power via different
means)?
Since I am assuming the community they think was destroyed by Macros
was the Lisp community, and Lisp has the ultimate Macro system, I
thought I'd bring the question over here. Do you think Macros are
useful and if you could do it all over again, would you allow Macros
into the language?
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
Joe Marshall
> So I thought I'd pose the question here. Do you think Macros have
> destroyed the Lisp community?
no
> Were Macros responsible for offspring
> languages such as Scheme?
no
> If Macro's weren't allowed into Lisp would
> Lisp be a stronger more vibrant community?
no
> Without Macros would Lisp
> be as powerful (ie, can you accomplish the same power via different
> means)?
er, it's turing complete....
> Since I am assuming the community they think was destroyed by Macros
> was the Lisp community, and Lisp has the ultimate Macro system, I
> thought I'd bring the question over here. Do you think Macros are
> useful and if you could do it all over again, would you allow Macros
> into the language?
well duh.....
Peter Seibel
> Ok, so on comp.lang.python we were having a discussion of Ruby vs.
> Python. Somehow, we got onto the topic of Macros. Personally I
> really like Macros, so I was defending the idea of Macros in Python.
> However a large group of people are diametrically opposed to Macros.
>
> Their logic goes something like this:
> 1. Macros are useful
> 2. Macros in Python would be useful
> 3. Macros in Python would be used a lot
> 4. Using Macros in Python would splinter the community and destroy
> Python.
>
> So I thought I'd pose the question here. Do you think Macros have
> destroyed the Lisp community?
No. Why would they have? I think you could apply the same analysis to
user-defined classes:
1. Classes are useful.
2. Classes in Python would be useful.
3. Classes in Python would be used a lot.
4. Using Classes in Python would splinter the community and destroy Python.
Do you think Classes have destroyed Python?
Or replace "classes" with "functions". The thing macros, classes, and
functions all have in common is they are a way of abstracting some
part of a computer program. The only difference with macros is that
they provide a way to create syntactic abstractions--i.e. they allow
you to express once a syntactic idiom rather than writing it out by
hand over and over.
This is a big difference in terms of the expressive power it gives the
programmer but there's no particular reason to think that this one
kind of abstraction is more likely to splinter a community.
I assume the assumption that leads to this fear is that one group of
programmers will write some macros and start using them. Then other
programmers, who want to understand their code will have to understand
those macros. If the other programmers don't like the macros they will
refuse to work on the code that uses them. Soon you have a schism. But
the same thing could happen with classes: I write some fancy-pants
class and use it in all my code. My friends all dig it and start using
it. But other programmers think my class is stupid and poorly designed
so they refuse to even look at our code. Soon we have a class-based
schism.
The only reason to think that this can't happen with classes but it
can (or is likely to) with macros is if you believe that expressing
things with classes so constrains your ability to express new ideas
that all programs expressed with classes will have a bland milquetoast
consistency that won't offend anyone. But I'm not sure I want to
program in a language that is intentionally keeping me from expressing
things because it might offend someone.
> Were Macros responsible for offspring languages such as Scheme?
Definitely not. In fact one of the biggest differences between Scheme
and Common Lisp is that Scheme eschews the power of Common Lisp style
macros prefering a "weaker" but more "tractable" form of code
generation. (Well, officially, it does. Many actual Scheme
implementations provide some form of Common Lisp style macros because
they're so darn useful.)
> If Macro's weren't allowed into Lisp would Lisp be a stronger more
> vibrant community?
Extremely unlikely.
> Without Macros would Lisp be as powerful (ie, can you accomplish the
> same power via different means)?
No. Other than in the trivial sense of Turing equivalence. But I
assume you mean "expressive power" which is a question of human
psychology, etc.
> Since I am assuming the community they think was destroyed by Macros
> was the Lisp community, and Lisp has the ultimate Macro system, I
> thought I'd bring the question over here. Do you think Macros are
> useful and if you could do it all over again, would you allow Macros
> into the language?
Well, I wasn't there the first time but if *I* had to do it over again
I'd definitely include Common Lisp-style macros.
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Kenny Tilton
Doug Tolton wrote:
> Ok, so on comp.lang.python we were having a discussion of Ruby vs.
> Python. Somehow, we got onto the topic of Macros. Personally I
> really like Macros, so I was defending the idea of Macros in Python.
> However a large group of people are diametrically opposed to Macros.
>
> Their logic goes something like this:
> 1. Macros are useful
> 2. Macros in Python would be useful
> 3. Macros in Python would be used a lot
> 4. Using Macros in Python would splinter the community and destroy
> Python.
Tell them it's not so bad being a dead language, so they should err on
the side of doing the Useful Thing.
At the talk to the FS Lisp-Curious, I tried to show my cool Lisp
features were useful by re-inventing Cells over the keyboard. Each macro
below started as non-macro, handmade code. Once it was working and I
wanted to do the same for other slots, I first made it a macro.
I only got as far as cacheing the result, so nothing about dependency
tracking or state change propagation, or even echoing:
(defmacro cellify (class-name slot-name)
`(defmethod ,slot-name ((self ,class-name)
&aux (sv (slot-value self ',slot-name)))
(typecase sv
(function (funcall sv self))
(otherwise sv))))
(defmacro defmodel (class superclasses (&rest slots))
`(progn
(defclass ,class ,superclasses
,slots)
,@(mapcar (lambda (slot)
(destructuring-bind
(slotname &key initarg accessor)
slot
(declare (ignore slotname initarg))
`(cellify ,class ,accessor)))
slots)))
(defmacro c? (&body code)
`(let ((cache :unbound))
(lambda (self)
(declare (ignorable self))
(if (eq cache :unbound)
(progn
(print '(calcing ,@code))
(setf cache (progn ,@code)))
cache))))
(defmodel box ()
((left :initarg :left :accessor left)
(right :initarg :right :accessor right)))
(defun test ()
(let* ((a (make-instance 'box
:left 0
:right (c? (random 30))))
(b (make-instance 'box
:left (lambda (self) (+ 2 (right a)))
:right (lambda (self) (+ 10 (left self))))))
(print (list :a a (left a) (right a)))
(print (list :b b (left b) (right b)))))
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Erann Gat
wrote:
> Ok, so on comp.lang.python we were having a discussion of Ruby vs.
> Python. Somehow, we got onto the topic of Macros. Personally I
> really like Macros, so I was defending the idea of Macros in Python.
> However a large group of people are diametrically opposed to Macros.
>
> Their logic goes something like this:
> 1. Macros are useful
> 2. Macros in Python would be useful
> 3. Macros in Python would be used a lot
> 4. Using Macros in Python would splinter the community and destroy
> Python.
I was with you up until #4. Then my head spun around 360 degrees. Ouch.
> So I thought I'd pose the question here. Do you think Macros have
> destroyed the Lisp community?
<irony>No, that was accomplished by other means.</irony>
> Were Macros responsible for offspring languages such as Scheme?
No, that was Sussman and Steele's fault (though they did use macros to
implement early versions of Scheme, and the practice continues to this
day).
> If Macro's weren't allowed into Lisp would
> Lisp be a stronger more vibrant community?
If templates weren't alowed in C++ would that make C++ a stronger more
vibrant community?
> Without Macros would Lisp
> be as powerful (ie, can you accomplish the same power via different
> means)?
No.
> Since I am assuming the community they think was destroyed by Macros
> was the Lisp community, and Lisp has the ultimate Macro system, I
> thought I'd bring the question over here. Do you think Macros are
> useful and if you could do it all over again, would you allow Macros
> into the language?
Ah, I get it now. The reasoning goes like this:
1. Lisp is dead.
2. All of Lisp's features except macros have been incorporated into Python.
3. Python is not dead.
4. Therefore, it must be the one remaining feature that Lisp has that
python lacks that was responsible for it's death.
<irony>Makes sense to me.</irony>
E.
P.S. You can tell them over in comp.lang.python that Lisp was killed not
by macros but by the metaobject protocol. That ought to keep them amused
for a few more years.
Wade Humeniuk
"Doug Tolton" <dto...@yahoo.com> wrote in message
news:jcc7kvk7dfji9o1oo...@4ax.com...
> Ok, so on comp.lang.python we were having a discussion of Ruby vs.
> Python. Somehow, we got onto the topic of Macros. Personally I
> really like Macros, so I was defending the idea of Macros in Python.
> However a large group of people are diametrically opposed to Macros.
>
Wow, language wars in a group other than c.l.l.!
> Their logic goes something like this:
> 1. Macros are useful
> 2. Macros in Python would be useful
> 3. Macros in Python would be used a lot
> 4. Using Macros in Python would splinter the community and destroy
> Python.
>
Just like nuclear weapons technology, when the technology is out,
and its useful then you cannot put the Genie back in the bottle. Macros
are such a useful construct, that they are out and will be used. If they
are not included in Python, then someone will develop a preprocessor
front-end to add the functionality. It sounds like Python is now being
used enough where people now see a need macros. Lisp probably
went through that stage a long time ago. Python will not be able
to resist evolving anymore that Lisp did. This was one of the
major reasons I started to use CL, I DID NOT WANT to keep
reinventing the wheel. All those wheels I was implementing in
other languages like C, to my pleasent surprise, had already
been done in CL.
> So I thought I'd pose the question here. Do you think Macros have
> destroyed the Lisp community? Were Macros responsible for offspring
> languages such as Scheme? If Macro's weren't allowed into Lisp would
> Lisp be a stronger more vibrant community? Without Macros would Lisp
> be as powerful (ie, can you accomplish the same power via different
> means)?
>
> Since I am assuming the community they think was destroyed by Macros
> was the Lisp community, and Lisp has the ultimate Macro system, I
> thought I'd bring the question over here. Do you think Macros are
> useful and if you could do it all over again, would you allow Macros
> into the language?
Human beings need expressive powers to reduce their workload. Macros
are a part of that. Even those who are fighting against macros know
this, their real agenda is to curtail other programmers "free speech".
Wade
Nikodemus Siivola
> Python will not be able to resist evolving anymore that Lisp did.
Except that I'm under the impression that implementing CL-style
macroes requires that code is written "as parse-trees" as opposed to
syntax -- whether those trees are marked up by parentheses or
something else entirely.
Given syntax you have to make do with either special purpose
constructs for transforming the code (urgh), or have a "lesser" macro
system (eg. Dylan's).
Anyways, interesting question since what brought me to CL was the way
macroes and multiple dispatch were mentioned as "would be nice, but
won't happen" in Ruby-related discussions. ,)=
Cheers,
-- Nikodemus
Steven E. Harris
> I only got as far as cacheing the result, so nothing about
> dependency tracking or state change propagation, or even echoing:
Thanks for the compelling sample. I've been enjoying playing around
with it, and can see a bit of what Cells must be about.
--
Steven E. Harris :: seha...@raytheon.com
Raytheon :: http://www.raytheon.com
Pascal Costanza
Doug Tolton <dto...@yahoo.com> wrote:
> So I thought I'd pose the question here. Do you think Macros have
> destroyed the Lisp community? Were Macros responsible for offspring
> languages such as Scheme? If Macro's weren't allowed into Lisp would
> Lisp be a stronger more vibrant community? Without Macros would Lisp
> be as powerful (ie, can you accomplish the same power via different
> means)?
My impression is that many people outside of the Lisp community think
that it is extremely important to have an agreed upon set of language
constructs and that it should be fixed. They think that such a fixed set
of language constructs ensures readability of source code across a large
community of programmers.
Macros are typically described as a facility that allows you to design
your own language constructs as extensions of the base language that are
not distinguishable from that of the base language. Those people who
believe in the "fixed set of constructs" notion are strongly scared by
the notion of an extensible programming language.
However, what they don't understand is that macros allow you to design
domain-specific languages that are tailored _exactly_ to the needs of
the problem domain at hand. No amount of language design can provide you
this power in the fixed-set world. The problems with fixed-set languages
is that all abstractions leak. Lisp-style macros can never leak, by
definition. No matter what problems occur, you have the guarantee that
you can work around it and typically find a good solution that gives you
exactly what you need.
For these reasons, I don't think that macros will fit with Python's
notion of "there's only one way to do it".
> Since I am assuming the community they think was destroyed by Macros
> was the Lisp community, and Lisp has the ultimate Macro system, I
> thought I'd bring the question over here. Do you think Macros are
> useful and if you could do it all over again, would you allow Macros
> into the language?
You're not asking the right question. The right question is this:
"Should I switch to Common Lisp?"
Yes, you should. ;)
Pascal
Doug Tolton
wrote:
Interestingly I did use the function analogy, but for some reason they
just didn't get it. There seems to be some mental blockage and they
don't realize that Macros are just a high level abstraction of the
language. It must be as you say, because it's a synctactic idiom.
Their logic has been driving me to distraction.
>This is a big difference in terms of the expressive power it gives the
>programmer but there's no particular reason to think that this one
>kind of abstraction is more likely to splinter a community.
>
>I assume the assumption that leads to this fear is that one group of
>programmers will write some macros and start using them. Then other
>programmers, who want to understand their code will have to understand
>those macros. If the other programmers don't like the macros they will
>refuse to work on the code that uses them. Soon you have a schism. But
>the same thing could happen with classes: I write some fancy-pants
>class and use it in all my code. My friends all dig it and start using
>it. But other programmers think my class is stupid and poorly designed
>so they refuse to even look at our code. Soon we have a class-based
>schism.
>
>The only reason to think that this can't happen with classes but it
>can (or is likely to) with macros is if you believe that expressing
>things with classes so constrains your ability to express new ideas
>that all programs expressed with classes will have a bland milquetoast
>consistency that won't offend anyone. But I'm not sure I want to
>program in a language that is intentionally keeping me from expressing
>things because it might offend someone.
>
That's what has been so frustrating about this conversation with them.
They all agree that Macros would be useful and powerful, but they see
that as a problem!! The number one claim is that it will fracture and
destroy the community. They must be referring to the Lisp community
in this discussion as nothing else I'm aware of offers
I guess when it comes right down to it, if the Macros in Python ended
up being as disappointing as their implementation of Lambda's it would
be a milquetoast implementation.
It's been a disappointing discussion, but ultimately I guess I don't
care that much because my heart is with Lisp. I just do Python at
work.
Doug Tolton
wrote:
I think this goes right to the heart of the matter. They really do
seem to believe "there's only one way to do it". They also seem to
believe that nobody but Guido Van Rossum is capable of designing a
language. I mentioned that I thought even a medium skill language
designer should be able to design a language that maps better to their
specific application domain than a general purpose programming
language would (of course implementation is a different story.) Their
reaction to this was mildly amusing as they viewed my statement as
borderline sacrilegious.
The response was a comparison to music. They said that is akin to
saying that any musician is capable of composing music better for
their specific instrument better than Beethoven was at composing
general purpose music. I think that argument is a ridiculous
comparison. The application domain is still the same. If you are
talking about adapting music to a brand new instrument that plays an
entirely different music scale, then we'd be talking a closer
argument. Although I still don't think it maps appropriately.
>> Since I am assuming the community they think was destroyed by Macros
>> was the Lisp community, and Lisp has the ultimate Macro system, I
>> thought I'd bring the question over here. Do you think Macros are
>> useful and if you could do it all over again, would you allow Macros
>> into the language?
>
>You're not asking the right question. The right question is this:
>"Should I switch to Common Lisp?"
>
>Yes, you should. ;)
Yeah, as I mentioned earlier, even if they did do macros I still think
I would be disappointed. The Lambda's they implemented are a joke, in
Python a Lambda is specifically restricted to being one line long!!
The more familiar I become with Lisp, the more I realize there is not
another language comaparable. Python is nice because it supports some
of the features I've come to love in Lisp, but it just isn't powerful
enough to replace Lisp.
Now if I could just get a list job...I mean I've been posting on
comp.doug.wants.a.lisp.job for the last 20 years, but there has
*never* been a single job posted there. There just must not be *any*
Lisp jobs anywhere in the *universe*!! ;)
Barry Margolin
Pascal Costanza <cost...@web.de> wrote:
>However, what they don't understand is that macros allow you to design
>domain-specific languages that are tailored _exactly_ to the needs of
>the problem domain at hand. No amount of language design can provide you
>this power in the fixed-set world.
Right. What seems to happen outside the Lisp community is that when users
discover that their language doesn't really fit the problem domain well,
they go off and design an entirely new language. I think that's how Perl
came about: shell script, awk, and sed were each partial solutions to the
application domain of system administration automation, but none of them
were complete, so someone went and designed a new language that combined
aspects (both good and bad) of all of them.
And then as they decided that there were features that it lacked, they had
to wait for developers to augment the language. Compare that to Lisp's
evolution, which has primarily been done by the users themselves using
macros (even many OO extensions can be implemented without changing the
base language, although adding it to the implementation allows for better
optimization).
--
Barry Margolin, barry.m...@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Frank A. Adrian
> P.S. You can tell them over in comp.lang.python that Lisp was killed not
> by macros but by the metaobject protocol. That ought to keep them amused
> for a few more years.
Actually, it was the fact that the Symbolics keyboard could not become
standard due to its weight (probably caused by the weight of the additional
super-, hyper-, et. al. keys). This killed Lisp development forever. They
should beware anyone trying to build a Python-specific keyboard, as it will
be the death knell for the language.
faa
P.S. Hey, it makes as much sense as the thought process in the original
post!
Frank A. Adrian
> Their logic has been driving me to distraction.
This is why their language is eventually doomed to the dustbin of history.
As far as I can see, Python adds nothing new to the world of computer
languages other than yet another syntax. If their average user's (and the
language) logic is as screwed up as their arguments, there's really nothing
there. I'd try to talk to your organization about switching from this
language that will obviously die to one that has withstood the test of time
- like Lisp.
faa
Erann Gat
I see I have made myself clear.
E.
Larry Clapp
> Ok, so on comp.lang.python we were having a discussion of Ruby vs.
> Python. Somehow, we got onto the topic of Macros. Personally I
> really like Macros, so I was defending the idea of Macros in Python.
> However a large group of people are diametrically opposed to Macros.
>
> Their logic goes something like this:
> 1. Macros are useful
> 2. Macros in Python would be useful
> 3. Macros in Python would be used a lot
> 4. Using Macros in Python would splinter the community and destroy
> Python.
:)
I thought Python had run-time code evaluation. Couldn't just about
any moderately skilled Python hacker add his own macro system? Which
would they rather have: lots of (arguably) hard-to-understand macros,
or lots of (probably) incompatible /macro systems/? Eventually,
people that want macros will create them. Do the people that *don't*
want them, not-want them enough to deal with several incompatible (and
probably buggy and slow) versions of them?
> So I thought I'd pose the question here. Do you think Macros have
> destroyed the Lisp community? Were Macros responsible for offspring
> languages such as Scheme? If Macro's weren't allowed into Lisp would
> Lisp be a stronger more vibrant community? Without Macros would Lisp
> be as powerful (ie, can you accomplish the same power via different
> means)?
No. I don't know. I don't know, but I doubt it. Probably -- Lisp
has EVAL, too. :)
-- Larry
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Kenny Tilton
Steven E. Harris wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>I only got as far as cacheing the result, so nothing about
>>dependency tracking or state change propagation, or even echoing:
>
>
> Thanks for the compelling sample. I've been enjoying playing around
> with it, and can see a bit of what Cells must be about.
>
Cool. I've had great fun with the little suckers over the years, glad
you like them. I started to toss off the really fun part, where changing
a non-ruled slot propagates to ruled slots that accessed them at some
point, only to realize that that is where a /lot/ of code gets written.
A full implementation is available on my web site along with some sorry
doc (the "Cell basics" bit is OK), and maybe tomorrow I will be able to
put a zip up on my sourceforge Cells project.
Adam Warner
> That's what has been so frustrating about this conversation with them.
> They all agree that Macros would be useful and powerful, but they see
> that as a problem!! The number one claim is that it will fracture and
> destroy the community.
Doug, I saved a June reference from a Java blog that has links to a
parallel discussion occurring in the Java community. It's to do with
keeping a "Language for the Masses" (LFM) rather than tailoring the
"Language for Smart People" (LFSM).
"Java is a Language for the Masses" by Carlos Perez
<http://www.artima.com/weblogs/viewpost.jsp?thread=5246>
It is also about keeping language construction out of the hands of the
pleb. Gilad Bracha, "computational theologist" at Sun writes: "Seriously,
some formulations of macros are well structured enough to prevent the
onerous kinds of abuse that have given macros a dubious reputation in the
C culture. Nevertheless, we don't plan on adding a macro facility to Java
any time soon. A major objection is that we do not want to encourage the
development of a wide variety of user-defined macros as part of the Java
culture."
You may discover that those objecting to macros are currently the
gatekeepers of language construction--and they want to keep it that way.
Objections related to preserving language culture and community are
sincere. It's just that the language leaders have the mental model of a
community designed as a pyramid, with them firmly at the top.
Regards,
Adam
Thomas F. Burdick
[ quoting from a weblog ]
> It is also about keeping language construction out of the hands of the
> pleb. Gilad Bracha, "computational theologist" at Sun writes:
The most stunning part of this guys comments is:
In general, once can contrast the Scheme-like philosophy of using a
small number of very general constructs, with the more mainstream
approach of having a great many highly specialized constructs, as in
C or Modula style languages.
Java is clearly in the latter camp. Most Java developers are happy
to have dedicated, narrowly focused solutions that are tailored to a
specific problem. I am keenly aware of the drawbacks of such an
approach, but I don't see it changing very quickly.
Wow. That's either amazingly ignorant, or dishonest. Surely, this guy
must know that Scheme did not invent macros, and in fact was a
latecomer (in the Lisp family, at least). If he doesn't, that's
remarkably ignorant, for a language designer. If so, what could be
his motivation for contrasting Java/no-macros with Scheme/macros,
instead of -- say -- CommonLisp/macros. To slander the idea of macros
with overly-academic associations, perhaps?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Lars Brinkhoff
> with "functions".
This is starting to look a bit like the "Macros Make Me Mad" thread:
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02030.html
and Guy Steele's tongue-in-cheek replies:
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02068.html
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02069.html
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02070.html
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Jacek Generowicz
> 1. Lisp is dead.
> 2. All of Lisp's features except macros have been incorporated into Python.
> 3. Python is not dead.
> 4. Therefore, it must be the one remaining feature that Lisp has that
> python lacks that was responsible for it's death.
> P.S. You can tell them over in comp.lang.python that Lisp was killed not
> by macros but by the metaobject protocol. That ought to keep them amused
> for a few more years.
Or scare the hell out of them, given that they have recently acquired
a MOP (well, sort of).
Jacek Generowicz
> As far as I can see, Python adds nothing new to the world of computer
> languages other than yet another syntax.
Python seems to be one of the better languages around, it many ways
closer to Lisp than most others ... and yet it is extremely easy to
learn; it brings immense expressive power to the fingertips of many
who would not be able to reach it in Python's absence.
I'd say that what it adds to the world of computer science, is
bringing a large number of people closer to Lisp.
I think that there are a lot of people, particularly those whose main
activity is not computer programming, for whom Python is exactly the
right language.
It fulfils an excellent role as "the amateur's lisp". I mean no
disrespect to Python in this phrase.
Kenny Tilton
Lars Brinkhoff wrote:
> Peter Seibel <pe...@javamonkey.com> writes:
>
>>Doug Tolton <dto...@yahoo.com> writes:
>>
>>>Do you think Macros have destroyed the Lisp community?
>>
>>Do you think Classes have destroyed Python? Or replace "classes"
>>with "functions".
>
>
> This is starting to look a bit like the "Macros Make Me Mad" thread:
> http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02030.html
> and Guy Steele's tongue-in-cheek replies:
> http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02068.html
> http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02069.html
> http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02070.html
>
Two interesting things. One, Steele got the parallelism wrong when he
wrote stuff like, paraphrasing "I expect classes to be perfect". I
thought he was a bright guy. <g>
Second, one of the Pythonistas used /precisely/ the same mocking
mimickry in reply to a great post on macros. But when he got to the crux
(how is a macro more inscrutable than a class or function?) he tried
sneaking by with a bogus analogue. (just called him on it. <g>)
Jacek Generowicz
> It sounds like Python is now being used enough where people now see
> a need macros.
To me, it looks like the only proponents of macros on c.l.py are those
who appreciate Lisp macros. (Well, there were a few who seemed to
think that the discussion was about C-style macros.)
> I DID NOT WANT to keep reinventing the wheel. All those wheels I
> was implementing in other languages like C, to my pleasent surprise,
> had already been done in CL.
Funny, one guy claimed that he prefers designing a completely new
language when Python doesn't quite fit his domain, while using a macro
to make an existing language move towards the domain would discourage
code reuse.
> Human beings need expressive powers to reduce their workload. Macros
> are a part of that. Even those who are fighting against macros know
> this, their real agenda is to curtail other programmers "free speech".
I think there is a niche for restrictive languages. But Python is
funny in this respect; they gave Guido as the Benevolent Dictator For
Life and being restrictive is somehow part of the culture; yet Python
is one of the most permissive languages around.
Mario S. Mommer
> "Wade Humeniuk" <wa...@nospam.nowhere> writes:
>
> > It sounds like Python is now being used enough where people now see
> > a need macros.
>
> To me, it looks like the only proponents of macros on c.l.py are those
> who appreciate Lisp macros. (Well, there were a few who seemed to
> think that the discussion was about C-style macros.)
What I think has been totally overlooked over there is how difficult
it may be to produce a decent macro system with a syntax that is not
that of lisp. We know that the designers of dylan did that, but I
wonder how much they tweaked the dylan syntax for it to become
possible.
Steven E. Harris
> I started to toss off the really fun part, where changing a
> non-ruled slot propagates to ruled slots that accessed them at some
> point, only to realize that that is where a /lot/ of code gets
> written.
I studied your posted code to make sure that this kind of "active"
propagation /does not/ happen, and wrote some tests to reassure myself
why that was a sound decision: the new value will be noticed the next
time a dependent slot is read.
In your posted example, I tried changing (right a), and confirmed that
a subsequent read of (left b) picked up on the change in a. If (right
a) is a "non-ruled" slot, and (left b) is a "ruled slot that accessed
(right a) at some point," and the change is already picked up, then
why do you need to add more code to handle this propagation?
Kenny Tilton
I'm lost, show me what you did. :) Note that once a rule calculates a
value, that is all it ever returns:
(if (eq cache :unbound)
(setf cache (progn ,@code))
cache)
Maybe you ran once, changed (right a) and then reran? you were making
new closures and they all start out unbound.
Were you asking why propagate? I think in the code I had (left a) as
plain old zero, and (right a) was silly: (c? (random 30)). Imagine
instead that (right a) is useful, such as (c? (* (length (text$ self))
(avg-char-width (font self)))).
Now they type some more text, and (text$ self) (another cell!) gets
bigger. Assuming we are building a widget that stretches to the size of
the enclosed text, we want (right a) to be recalculated.
In the example, change (right a) to be (c? (+ 10 (left self))). Then
after printing out all the values:
(setf (left a) 100)
[...print again...]
The you'll then get left=100, right still=10. I hope. :)
Miles Egan
> Yeah, as I mentioned earlier, even if they did do macros I still think
> I would be disappointed. The Lambda's they implemented are a joke, in
> Python a Lambda is specifically restricted to being one line long!!
It's really the combination of s-expr syntax and macros that makes
lisp so flexible. I'd rather have macros than not have them in any
language, but without a programmable syntax they're not nearly as
useful.
> The more familiar I become with Lisp, the more I realize there is not
> another language comaparable. Python is nice because it supports some
> of the features I've come to love in Lisp, but it just isn't powerful
> enough to replace Lisp.
Lisp really is in its own class.
--
miles egan
mi...@rddac.com
reverse the domain name to find me
OpenPGP/GPG Key 0x01F53D51 @ wwwkeys.us.pgp.net
Kaz Kylheku
> Python. Somehow, we got onto the topic of Macros. Personally I
> really like Macros, so I was defending the idea of Macros in Python.
> However a large group of people are diametrically opposed to Macros.
>
> Their logic goes something like this:
> 1. Macros are useful
> 2. Macros in Python would be useful
> 3. Macros in Python would be used a lot
> 4. Using Macros in Python would splinter the community and destroy
> Python.
That's like saying that allowing Linux users to use either vi or emacs
editors splinters the Linux community and destroys Linux.
Customizing some aspect of a substrate does not interfere with its
interoperability. Macros don't destructively change the Lisp image
into a different language which will no longer accept code. A
different text editor or shell does not change Linux into a different
operating system that someone else can't use; two hackers could use
the same machine, and have it conform to their own customizations, and
use each other's software.
All programming is an exercise in building up a custom language. Even
if you are programming in a language like C, you write functions,
thereby creating a programming vocabulary in terms of which other
parts of the program are written. Someone who wants to maintain your
program has to learn that vocabulary, or at least a subset that is
relevant to the maintenance task.
When you are faced with the call to an unfamiliar function, you know
that the argument expressions are evaluated before the call takes
place. Beyond that, you don't know anything; you must study that
function or its documentation. With a macro, you don't know the
evaluation rules of the arguments. In all other respects, you have the
same learning to do. The use of well-designed macros can make the code
much smaller and more understandable and maintainable, so learning
someone's custom macro language may require much less effort than
learning the vocabulary of a purely function-based program that solves
the same problem.
Macros are needed to solve problems. If I need macros to solve a
problem, but using macros means leaving some community that is held
together by ignorance, I will gladly ditch the community.
Shared stupidity is not community. Community, in the context of a
programming language, means that there exist numerous vendors of
quality implementations, that development is going on, and that if you
need developers, you can find them.
> So I thought I'd pose the question here. Do you think Macros have
> destroyed the Lisp community? Were Macros responsible for offspring
> languages such as Scheme?
Scheme was the result of experimentation with programming language
features that could not be easily or efficiently hacked with Lisp
macros, such as lexical scope and continuations. Some of the features,
notably lexical scope, made their way back into Lisp.
You seem to be insinuating that the production of offspring language
is a bad thing. But to prevent offsprings, you have to sterilize,
contracept or else abstain from pleasure. :)
> If Macro's weren't allowed into Lisp would
> Lisp be a stronger more vibrant community?
Other than deliberate, self-imposed ignorance, what force could defend
this prohibition against macros? If macros weren't allowed into Lisp,
it would be some dumbed-down language that is only *called* Lisp, but
is so badly designed that not only doesn't it have macros, they are
hard to retrofit by users who know all about macros and would like to
use them. The smart people would use something that has support for
macros, only it would be called something other than Lisp. Same world,
different labels.
Kaz Kylheku
> In article <jcc7kvk7dfji9o1oo...@4ax.com>,
> Doug Tolton <dto...@yahoo.com> wrote:
>
> > So I thought I'd pose the question here. Do you think Macros have
> > destroyed the Lisp community? Were Macros responsible for offspring
> > languages such as Scheme? If Macro's weren't allowed into Lisp would
> > Lisp be a stronger more vibrant community? Without Macros would Lisp
> > be as powerful (ie, can you accomplish the same power via different
> > means)?
>
> My impression is that many people outside of the Lisp community think
> that it is extremely important to have an agreed upon set of language
> constructs and that it should be fixed. They think that such a fixed set
> of language constructs ensures readability of source code across a large
> community of programmers.
That is my impression also; this is a commonly held view.
> Macros are typically described as a facility that allows you to design
> your own language constructs as extensions of the base language that are
> not distinguishable from that of the base language. Those people who
> believe in the "fixed set of constructs" notion are strongly scared by
> the notion of an extensible programming language.
But their view is without any technical merit, because the languages
that they use allow them to write *functions* that are
indistinguishable from the standard library functions that come with
their language.
A nicely formatted, ``readable'' piece of source that relies on
unfamiliar functions is no more or less understandable than a nicely
formatted piece of code that relies on unfamiliar macros.
> However, what they don't understand is that macros allow you to design
> domain-specific languages that are tailored _exactly_ to the needs of
> the problem domain at hand. No amount of language design can provide you
> this power in the fixed-set world.
Not only that, but they don't undestand that in Lisp programming, you
sometimes do exactly what is done in their favorite programming
language: namely, write a truckload of functions or class methods to
implement some software component. But that in Lisp, there is the
added step of writing macros which greatly simplify the *use* of those
functions and classes. The use of function libraries must obey certain
rules. The true functional units of a library are not the individual
methods, but transactions that must correctly coordinate the calls to
several methods, possibly requiring the local retention of information
from some calls to pass to the others. Macros let us capture those
transactions. These transactions effectively correspond to *use cases*
of the library. It's easier for the user to have constructs that
represent relevant use cases than to work with constructs that
represent tiny steps of use cases, which he or she must slap together
in the right way.
Not all such use cases can be easily hidden behind yet another
function, because portions of the use cases are left abstract; they
require the insertion of custom logic from the actor, logic which
wants to refer to entities that are visible in the lexical contour
where the use case is taking place.
Steven E. Harris
> I'm lost, show me what you did. :)
You will not be impressed, but I'll keep it simple:
(defun test ()
(let* ((a (make-instance 'box
:left 0
:right (c? (random 30))))
(b (make-instance 'box
:left (lambda (self) (+ 2 (right a)))
:right (lambda (self) (+ 10 (left self))))))
(print (list :a a (left a) (right a)))
(print (list :b b (left b) (right b)))
(setf (right a) 40) ; <-- Changed a.
(print (list :b b (left b) (right b)))))
(test)
To your posted code, I added a modification to (right a). I presume
that this overwrites the would-be cached random value produced by the
initial c? macro. Then, I just printed b's slots again to see how they
changed.
> Note that once a rule calculates a value, that is all it ever
> returns:
>
> (if (eq cache :unbound)
> (setf cache (progn ,@code))
> cache)
Well, that's a caching rule, right? Your example slots in box b above
did not use the caching c? macro.
> Maybe you ran once, changed (right a) and then reran? you were
> making new closures and they all start out unbound.
No, I think you'll see the behavior I described if you run the test
shown above.
> Were you asking why propagate? I think in the code I had (left a) as
> plain old zero, and (right a) was silly: (c? (random 30)). Imagine
> instead that (right a) is useful, such as (c? (* (length (text$ self))
> (avg-char-width (font self)))).
>
> Now they type some more text, and (text$ self) (another cell!) gets
> bigger. Assuming we are building a widget that stretches to the size
> of the enclosed text, we want (right a) to be recalculated.
Well, isn't the problem really with cache invalidation? If you didn't
use caching, the widget would stretch properly when it next queried
(right a), provided some redraw or resize operation gets kicked off
somewhere.
> In the example, change (right a) to be (c? (+ 10 (left self))). Then
> after printing out all the values:
>
> (setf (left a) 100)
> [...print again...]
>
> The you'll then get left=100, right still=10. I hope. :)
Indeed. But I'm not disappointed. When I studied your code, I assumed
that caching and dependent calculations didn't mix well. Your comments
since your first post make it sound as though you're building an
inverse dependency graph from the slot reads and using that graph to
propagate changes. I've been using a spreadsheet as my mental model
here and, now that I think of it, given that each cell's visibility is
akin to an instant subsequent read, changing any one cell would either
force every cell to be recalculated or force traversal of a dependency
graph to update a subset of the other cells.
But surely there must be applications where lazy updating would be
sufficient. Making that work with caching would be difficult.
Paolo Amoroso
> What I think has been totally overlooked over there is how difficult
> it may be to produce a decent macro system with a syntax that is not
> that of lisp. We know that the designers of dylan did that, but I
And Poplog.
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Kenny Tilton
Oops. Until you reposted my code I forgot the talk ended when I showed
off how C? could hide the cacheing, but before I then converted the
other rules to C? Sorry, all the other confusion stemmed from that
mistake of mine.
> Well, isn't the problem really with cache invalidation? If you didn't
> use caching, the widget would stretch properly when it next queried
> (right a), provided some redraw or resize operation gets kicked off
> somewhere.
Yes, that is where we started, but I knew eventually we would have to
cache calculations; it was way too slow once we had dozens of widgets.
> Indeed. But I'm not disappointed. When I studied your code, I assumed
> that caching and dependent calculations didn't mix well.
Takes a little work to get right, but it is hugely worth it. I talk
about it on my web site.
> Your comments
> since your first post make it sound as though you're building an
> inverse dependency graph from the slot reads and using that graph to
> propagate changes. I've been using a spreadsheet as my mental model
> here...
Exactimundo.
... and, now that I think of it, given that each cell's visibility is
> akin to an instant subsequent read, changing any one cell would either
> force every cell to be recalculated ...
Yes. But that is how my applications work. I call it animated
programming (because dataflow is used by people who are not letting the
data flow). In my, inputs go in one end, triggering a cascade of
recalculation. State change is manifested by an optional user-supplied
"on change" callback. It's a blast (just as spreadsheets beat the hell
out of doing them by hand).
>
> But surely there must be applications where lazy updating would be
> sufficient. Making that work with caching would be difficult.
>
I have never found a need for lazy propagation, but I am thinking about
throwing it in as option just to quiet down the many people who think
eager won't work. <g> It will be easy since I already have the
dependency graph and a flag that marks cells as invalid: just run up the
graph marking everything as invalid! Any time anybody accesses a slot
driven by such a cell, the rule will get kicked off. That's how it works
anyway. It will be a disaster, but as long as it is only a day's work
it's worth it not to have to argue the issue all the time.
That said, I have been toying with using lazy prop myself in RoboCup. A
client gets a steady stream of sight and body info, six and ten times a
second, out of which we build a stable world model. lazy prop would let
me build a very rich world model, confident it is not recalculated until
the client asks. Especially at tense moments such as executing a shot on
goal or even once I have decided to pass to a teammate, I do not much
care about a lot of things the world model might be recalculating all
the time.
The bad news is that any cell that wants to be lazy infects all cells
downstream from it (everyone who uses it directly or indirectly). But
then, I guess that is what we want.
The really bad news is that lazy is also inefficient! My mechanism stops
propagating when a rule computes the same value as last time. But if we
are just flagging things as invalid, we do not know where to stop! So
that optimization is lost. This hurts especially where I use synapses to
modulate change propagation. I might have a rule:
:alarm (c? (if (> (pressure self) (* .9 (rated-pressure self))
:on :off)
That rule does not have to run on every itty bitty change in pressure. A
synapse can express that: (pressure self (fSensitivity 5))
Again, lazy propagation must storm past any synapse and force things to
recalculate once they get accessed.
It will be interesting to see how lazy prop pans out in practice in the
RoboCup world model--I should be able to turn it on/off easily. Hey,
maybe the program does it dynamically when the action heats up? That
could be metacool.
Jacek Generowicz
> Customizing some aspect of a substrate does not interfere with its
> interoperability. Macros don't destructively change the Lisp image
> into a different language which will no longer accept code.
It seems that some of the people in c.l.py who are afraid of macros,
think that macros do just that.
Marco Antoniotti
Well, they also think that "forced indentation" is a good thing :)
Cheers
--
Marco
Doug Tolton
<jacek.ge...@cern.ch> wrote:
>> Human beings need expressive powers to reduce their workload. Macros
>> are a part of that. Even those who are fighting against macros know
>> this, their real agenda is to curtail other programmers "free speech".
>
>I think there is a niche for restrictive languages. But Python is
>funny in this respect; they gave Guido as the Benevolent Dictator For
>Life and being restrictive is somehow part of the culture; yet Python
>is one of the most permissive languages around.
Yeah I was thinking about this yesterday while I was home sick. Why
they are making the claim that Python should be a restrictive language
is odd to me. By allowing Metaclasses and Magic methods alone they
have already given the average joe the ability to make the language
perform in ways that would be completely unexpected.
Doug Tolton
wrote:
Yeah, I've been thinking about that a lot too. I really don't think
it would be possible to reproduce the powerful Macro system that Lisp
has in Python. Maybe not possible isn't the right wording, rather
highly improbable. It would also be much more difficult to use. The
continuity of Lisps syntax and the fact that everything is already in
a parse tree makes it vastly more useful and powerful than it would be
in Python. I still think it would be a good addition to that language
though, mainly because I want it to be more like Lisp. :)
Doug Tolton
wrote:
>You seem to be insinuating that the production of offspring language
>is a bad thing. But to prevent offsprings, you have to sterilize,
>contracept or else abstain from pleasure. :)
Sorry if that was the perception. I am not insinuating that. I think
Macros are a good thing, and I think giving the ability to create new
languages and / or Micro languages is a good thing. I wanted to bring
this post here, because on c.l.l people really get Macros, and I
wanted to get some opinions from people who really understand them,
not just claim to understand them in order to bolster their argument
against them.
Frank A. Adrian
> Yeah, I've been thinking about that a lot too. I really don't think
> it would be possible to reproduce the powerful Macro system that Lisp
> has in Python. Maybe not possible isn't the right wording, rather
> highly improbable.
Well, you can always check out what Dylan did as a basis for starting. They
did something similar. And, yes, it does get more complicated when you get
complex syntax involved.
faa
Doug Tolton
<use...@consulting.net.nz> wrote:
>Doug, I saved a June reference from a Java blog that has links to a
>parallel discussion occurring in the Java community. It's to do with
>keeping a "Language for the Masses" (LFM) rather than tailoring the
>"Language for Smart People" (LFSM).
>
>"Java is a Language for the Masses" by Carlos Perez
><http://www.artima.com/weblogs/viewpost.jsp?thread=5246>
Thanks for that link, that is a pretty good read. That does tend to
sum up the Java philosophy, which is I guess one of the reasons I've
never liked Java that well. ;)
Paul Graham has some good articles on Languages for Smart People vs.
Language for the Masses.
Pascal Costanza
>>What I think has been totally overlooked over there is how difficult
>>it may be to produce a decent macro system with a syntax that is not
>>that of lisp. We know that the designers of dylan did that, but I
>>wonder how much they tweaked the dylan syntax for it to become
>>possible.
>
> Yeah, I've been thinking about that a lot too. I really don't think
> it would be possible to reproduce the powerful Macro system that Lisp
> has in Python. Maybe not possible isn't the right wording, rather
> highly improbable. It would also be much more difficult to use.
Even if they decided to introduce a macro system, it wouldn't be clear
if we would really get what we want. For example, they would most
probably lead the whole discussion about hygienic macros again. In the
mind of someone who thinks that there should be only one way to do
something, macro hygiene probably sounds very attractive...
Pascal
Coby Beck
> On Thu, 21 Aug 2003 17:03:13 +1200, Adam Warner
> <use...@consulting.net.nz> wrote:
>
> >Doug, I saved a June reference from a Java blog that has links to a
> >parallel discussion occurring in the Java community. It's to do with
> >keeping a "Language for the Masses" (LFM) rather than tailoring the
> >"Language for Smart People" (LFSM).
> >
> >"Java is a Language for the Masses" by Carlos Perez
> ><http://www.artima.com/weblogs/viewpost.jsp?thread=5246>
>
> Thanks for that link, that is a pretty good read. That does tend to
> sum up the Java philosophy, which is I guess one of the reasons I've
> never liked Java that well. ;)
One quote (I did not verify it) attributed to "Gilad Bracha, the resident
Computational Theologist at Sun" caught my eye:
"The advantages of Java is that it easily serves as a lingua franca -
everyone can read a Java program and understand what is going on. User
defined macros destroy that property. Every installation or project can (and
will) define its own set of macros, that make their programs unreadable for
everyone else."
I seem to hear this objection quite a bit. I think well written and well
named macros have exactly the opposite effect. In fact, how is it any
different from an application specific set of classes and functions? I
really just don't get that objection. Do other have experiences that
support that concern?
Another eye catcher was this, attributed to William Grosso:
"The single best measure of whether a programming language is worth using
is: how well does it support communities. The social aspects of the language
dominate the technological aspects of the language"
Where can the dialogue begin?
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Doug Tolton
wrote:
I'm starting to wonder if this issue is like all the other
sufficiently polarized issues, until you get past some serious road
block you can't have a meaningful dialogue. Unfortunately that
usually has to happen in a one on one setting, and not in a setting
with a large audience where pride has become involved. I've been
reading the threads on the comp.lang.python about Macros, both Kenny
and Jacek have made some phenomenally insightful and knowledgeable
posts, yet the pythonists just don't seem to get it or refuse to get
it.
I have to wonder though, if they are arguing more from a fear point of
view than a rational experienced point of view. One of them admitted
that he's never been able to "get" Lisp, even with repeated attempts.
If you don't really understand macros, but have just heard bad things
about them, it would be really tough to have any kind of intelligent
discussion about them. Of course that doesn't stop some people.
Thien-Thi Nguyen
> The number one claim is that it will fracture and
> destroy the community.
only a community stuck in xor-thinking has this to fear.
tell them to strike the narrow, suck the marrow,
limp but follow the 'rise tomorrow.
rotate the crops, pull out the stops,
leave fields to fallow, lest yields go shallow.
coin the phrases, spread the praises,
but fear no fellow, not piqued not mellow.
thi
Scott L. Burson
> "The advantages of Java is that it easily serves as a lingua franca -
> everyone can read a Java program and understand what is going on. User
> defined macros destroy that property. Every installation or project can
> (and will) define its own set of macros, that make their programs
> unreadable for everyone else." [- attributed to Gilad Bracha]
>
> I seem to hear this objection quite a bit. I think well written and well
> named macros have exactly the opposite effect.
I agree; but I have noticed that my idea of "well written" is not
everyone's. A case in point is LOOP, which I have always detested and
refuse to use (except in its simple, keywordless form). I think it's
actually a good example of the kind of macro that Bracha is objecting to:
it creates an alternative sublanguage which doesn't let you do anything
new, but merely provides a collection of minor conveniences -- the value of
which, in my opinion, is not nearly sufficient to justify forcing readers
of the code to learn another set of keywords. The fact that it's enshrined
in the Lisp specification makes it, in my mind, something of a cautionary
tale here.
I suppose this is a minority view.
> In fact, how is it any
> different from an application specific set of classes and functions? I
> really just don't get that objection. Do other have experiences that
> support that concern?
I certainly have heard of Lisp programs whose authors got quite carried away
with macros. I don't recall ever having actually seen any such code, but
it isn't too hard to imagine that code could be made thoroughly
unintelligible that way.
Of course code can be made unintelligible with poorly designed classes and
methods, too. But I think more damage can be done with macros.
So given the charter of Python as a language, I am somewhat sympathetic to
the view that macros are too powerful for it. If they were added to the
language, chapters would have to be added to Python books explaining when
and how, and when not and how not, to use them; and the Python community
would have to absorb all that information, which means not just reading
those chapters, but convincing themselves that the recommendations are made
for good reasons, which for some rebellious souls will require that they go
ahead and make a mess of their code first.
Of course I prefer Lisp for my own use.
-- Scott
--
To send email, remove uppercase characters from address in header.
Jacek Generowicz
> I'm starting to wonder if this issue is like all the other
> sufficiently polarized issues, until you get past some serious road
> block you can't have a meaningful dialogue. Unfortunately that
> usually has to happen in a one on one setting, and not in a setting
> with a large audience where pride has become involved.
Yes, the FUD spreaders certainly get in the way of setting up a
dialogue with those who want to understand.
> I've been reading the threads on the comp.lang.python about Macros,
> both Kenny and Jacek have made some phenomenally insightful and
> knowledgeable posts, yet the pythonists just don't seem to get it or
> refuse to get it.
To be fair to them, I think some of them are getting quite a
bit. They're just not the most vocal ones. (I've got some off-list
replies which suggest this, at least.)
And it has to be said, I don't really see what Python macros could
look like. (I don't know enough Dylan.)
> I have to wonder though, if they are arguing more from a fear point of
> view than a rational experienced point of view.
There certainly seems to be the opinion flying around, that writing a
macro breaks the whole language for everyone around the world.
Pascal Costanza
> Coby Beck wrote:
>
>
>>"The advantages of Java is that it easily serves as a lingua franca -
>>everyone can read a Java program and understand what is going on. User
>>defined macros destroy that property. Every installation or project can
>>(and will) define its own set of macros, that make their programs
>>unreadable for everyone else." [- attributed to Gilad Bracha]
>>
>>I seem to hear this objection quite a bit. I think well written and well
>>named macros have exactly the opposite effect.
>
>
> I agree; but I have noticed that my idea of "well written" is not
> everyone's. A case in point is LOOP, which I have always detested and
> refuse to use (except in its simple, keywordless form). I think it's
> actually a good example of the kind of macro that Bracha is objecting to:
> it creates an alternative sublanguage which doesn't let you do anything
> new, but merely provides a collection of minor conveniences
But that's purely what programming languages are all about: to provide a
convenience level for the programmer!
If a language construct allows me to quickly see whether a piece of code
does the thing I want, that's convenience! And some iterations are just
better expressed in a loop style than in other styles...
Pascal
Douglas Philips
> I agree; but I have noticed that my idea of "well written" is not
> everyone's. A case in point is LOOP, which I have always detested and
> refuse to use (except in its simple, keywordless form).
I had avoided it altogether, but I suppose in its most harmless form it
is OK. 1/2 ;-)
> The fact that it's enshrined in the Lisp specification makes it, in my mind,
> something of a cautionary tale here.
As has been written in a few places, the ANSI Common Lisp process was
done at an interesting time and with (perhaps all too typical) political
agendas. I might go so far as to say that FORMAT has the same issues. I
concede FORMAT on the grounds that most languages seem to have I/O (or
O) issues that are just down right annoying. In true Lisp form, FORMAT
goes way over the top of most other languages formatting abilities...
> I suppose this is a minority view.
Hard to know, but I'm in that minority too. I found Graham's comments
about LOOP in ACL very much in harmony with my own feelings, esp. his
note on pages 411&412 (of the copy I have) (this is a note referring
back to page 242, where he asked: "why do we need loop if we have
map-int?"):
It might be argued that loop is more general, and that we
should not define many operators to do what we can do with one.
But it's only in a very legalistic sense that loop is one
operator. In that sense, eval is one operator too. Judged by
the conceptual burden it places on the user, loop is at least as
many operators as it has clauses. What's more, these operators
are not available separately, like real Lisp operators:
you can't break off a piece of loop and pass it as an argument
to another function, as you coud map-int.
> Of course code can be made unintelligible with poorly designed classes and
> methods, too. But I think more damage can be done with macros.
Its hard to have power useable for good that is also not useable for
evil. ;-)
> would have to absorb all that information, which means not just reading
> those chapters, but convincing themselves that the recommendations are made
> for good reasons, which for some rebellious souls will require that they go
> ahead and make a mess of their code first.
Nothing wrong with learning by doing.... ;-)
<D\'gou
Thomas F. Burdick
> One quote (I did not verify it) attributed to "Gilad Bracha, the resident
> Computational Theologist at Sun" caught my eye:
>
> "The advantages of Java is that it easily serves as a lingua franca -
> everyone can read a Java program and understand what is going on. User
> defined macros destroy that property. Every installation or project can (and
> will) define its own set of macros, that make their programs unreadable for
> everyone else."
>
> I seem to hear this objection quite a bit. I think well written and well
> named macros have exactly the opposite effect. In fact, how is it any
> different from an application specific set of classes and functions? I
> really just don't get that objection. Do other have experiences that
> support that concern?
In fact, if you look at what's actually used as a lingua franca (in CS
papers, or website examples) -- if the author is simply trying to
convey the algorithms or whatever, to a general audience, they
generally choose pseudo-code, not any real production language. This
is good, because it lets you gloss over details that are relevent only
to some subset of your readers. Macros let you implement the
psuedo-code itself, so I quite agree with you.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Eric Smith
> everyone's. A case in point is LOOP, which I have always detested and
> refuse to use (except in its simple, keywordless form). I think it's
Here is an example to help discuss the usefulness
of loop. This whet macro is implemented by a loop.
Whet is like let* with two differences. First, the
bindings have to all be initialized with non-nil
values, or the whet form immediately returns nil.
Second, the list of bindings is like a plist, to
reduce the number of parentheses. E.g.
(whet (a 1
b 2)
(values a b))
But the main reason to use whet instead of let* is
the testing of each binding, continuing only when
they are all true, and in particular not evaluating
the next binding if the previous binding is nil.
Because, there are a lot of application situations
where data is built in steps which can each succeed
or fail, with the failures returning nil, and the
next step not being possible after a failure.
Here is a loop version of the whet macro:
(defmacro whet (bindings &body body)
(loop with code = `(let () ,@body)
as (val name) on (reverse bindings) by #'cddr
as code = `(let ((,name ,val))
(when ,name ,code))
finally (return code)))
Someone should post a non-loop version, so we can
discuss how much convenience, if any, is added by loop.
Or if someone has a better loop version, they should
post that too. And of course we should keep in mind
that this one small example does not address most of
what you can do with loop. But it's good to have at
least one example in any such discussion, and hopefully
more examples will be posted by others.
Pascal Costanza
> Here is a loop version of the whet macro:
>
> (defmacro whet (bindings &body body)
> (loop with code = `(let () ,@body)
> as (val name) on (reverse bindings) by #'cddr
> as code = `(let ((,name ,val))
> (when ,name ,code))
> finally (return code)))
Here is a version of "whet" (aka when-let) implemented with reduce.
(defmacro when-let ((var form) &body body)
`(let ((,var ,form))
(when ,var
,@body)))
(defmacro when-let* (bindings &body body)
(reduce (lambda (binding body)
`(when-let (,(car binding) ,(cadr binding))
,body))
bindings :initial-value `(progn ,@body) :from-end t))
when-let takes of one binding and when-let* takes care of n bindings.
These implementations should be compatible with the ones of LispWorks.
Pascal
Marco Baringer
> Someone should post a non-loop version, so we can
> discuss how much convenience, if any, is added by loop.
while i _really_ like loop (and format) i think this is a horrible way
to use it. for me loop is about iterating, and this just doesn't
"feel" like iteration.
(defmacro whet ((&rest bindings) &body body)
(if bindings
`(let ((,(first bindings) ,(second bindings)))
(when ,(first bindings)
(whet ,(cddr bindings) ,@body)))
`(progn ,@body)))
of course, this solution only works because you want let* like
binding, doing let like binding would require an iterative solution,
which in which case i'd use loop.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Lars Brinkhoff
> Eric Smith wrote:
> > Here is a loop version of the whet macro:
Another variation:
http://groups.google.com/groups?selm=3248033830373991%40naggum.no
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>Eric Smith wrote:
>>
>>>Here is a loop version of the whet macro:
>>
>>Here is a version of "whet" (aka when-let) implemented with reduce.
>
>
> Another variation:
> http://groups.google.com/groups?selm=3248033830373991%40naggum.no
Thanks for the link. However, what do you mean by "variation" in this
context? EN doesn't provide any implementation in his post...
The only variations I can see is that the name is different and that you
can include type information in the binding declarations. Both are not
breathtaking IMHO.
Thanks anyway.
Pascal
Lars Brinkhoff
> > http://groups.google.com/groups?selm=3248033830373991%40naggum.no
> However, what do you mean by "variation" in this context?
This:
> The only variations I can see is that the name is different and that
> you can include type information in the binding declarations.
--
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>>http://groups.google.com/groups?selm=3248033830373991%40naggum.no
>>
>>However, what do you mean by "variation" in this context?
>
>
> This:
>
>
>>The only variations I can see is that the name is different and that
>>you can include type information in the binding declarations.
How do they contribute to the current topic, i.e. loop vs. recursion vs.
reduce?
Pascal
Kent M Pitman
> Another eye catcher was this, attributed to William Grosso:
>
> "The single best measure of whether a programming language is worth using
> is: how well does it support communities. The social aspects of the language
> dominate the technological aspects of the language"
>
> Where can the dialogue begin?
Heh. I might (on some days) agree with this if changed to:
The single most important aspect of a programming language is: how does it
support communities. The social aspects of the language dominate the
technical aspects of the language. Too bad questions like
"how well does this support the community?" are heavily subjective,
do not have a canonical answer, and easily manipulated for political ends.
For example, some languages (e.g, Ada and Java) are very controlling,
reducing the number of ways you can write a program, while others
(e.g., Common Lisp) are very flexible, offering many syntactically
and abstractionally distinct ways to write the same program. Freedom
and safety are not something that move in lockstep; they are almost
direct enemies of one another. In the world today, the reasons for
global terrorism can (by at least some analyses, and yes, I know there
are other views) be reduced to this question--is a heavily rigid,
orderly, religious society better than a free, chaotic, less
centrally/canonically principled one? I don't mean to start a big
political debate here on that--only to observe that people daily lose
their lives debating such matters, and so in a sense that's an existence
proof that this is a matter not likely to be easily seen through a
single, canonical lens of objectivity, and instead is, as I said,
intrinsically subjective.
Russell Wallace
Burdick) wrote:
>Wow. That's either amazingly ignorant, or dishonest. Surely, this guy
>must know that Scheme did not invent macros, and in fact was a
>latecomer (in the Lisp family, at least). If he doesn't, that's
>remarkably ignorant, for a language designer. If so, what could be
>his motivation for contrasting Java/no-macros with Scheme/macros,
>instead of -- say -- CommonLisp/macros. To slander the idea of macros
>with overly-academic associations, perhaps?
What you're not seeing is that from a Java guy's viewpoint, the
difference between Common Lisp and Scheme is utterly insignificant.
It's like going to Northern Ireland and saying "You're a Catholic,
right?" to a Protestant or vice versa - you can annoy people that way,
but a Buddhist or a Hindu would be scratching his head and going
"what's the difference?"
And incidentally I agree with him - I might have a slight preference
for Common Lisp over Scheme or vice versa, but I would much prefer to
program in either of them than Java.
However, if the masses all end up programming in a deliberately
dumbed-down language, that's fine with me; means my freedom to use
whatever I please gives me a competitive advantage.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Thomas F. Burdick
> On 20 Aug 2003 22:25:43 -0700, t...@famine.OCF.Berkeley.EDU (Thomas F.
> Burdick) wrote:
>
> >Wow. That's either amazingly ignorant, or dishonest. Surely, this guy
> >must know that Scheme did not invent macros, and in fact was a
> >latecomer (in the Lisp family, at least). If he doesn't, that's
> >remarkably ignorant, for a language designer. If so, what could be
> >his motivation for contrasting Java/no-macros with Scheme/macros,
> >instead of -- say -- CommonLisp/macros. To slander the idea of macros
> >with overly-academic associations, perhaps?
>
> What you're not seeing is that from a Java guy's viewpoint, the
> difference between Common Lisp and Scheme is utterly insignificant.
No, it's not! At least in this instance, it's not. He was comparing
Scheme's approach of having a few general, orthogonal features, with
Java's bige-language approach. In this case, Scheme and Java are very
different, but CL and Java are in the same boat.
Russell Wallace
Burdick) wrote:
>No, it's not! At least in this instance, it's not. He was comparing
>Scheme's approach of having a few general, orthogonal features, with
>Java's bige-language approach. In this case, Scheme and Java are very
>different, but CL and Java are in the same boat.
To a Common Lisp guy they may be, but to a Java guy they aren't.
Nils Goesche
> On 26 Aug 2003 11:40:14 -0700, t...@famine.OCF.Berkeley.EDU (Thomas F.
> Burdick) wrote:
>
> >No, it's not! At least in this instance, it's not. He was
> >comparing Scheme's approach of having a few general, orthogonal
> >features, with Java's bige-language approach. In this case, Scheme
> >and Java are very different, but CL and Java are in the same boat.
>
> To a Common Lisp guy they may be, but to a Java guy they aren't.
Why? Are you saying that Java Man's brain is not capable of making
even a simple abstraction like this? I don't think that's true, which
is why Thomas' remark ``If he doesn't, that's remarkably ignorant, for
a language designer.´´ seems right to the point.
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Russell Wallace
>wallacet...@eircom.net (Russell Wallace) writes:
>
>> To a Common Lisp guy they may be, but to a Java guy they aren't.
>
>Why? Are you saying that Java Man's brain is not capable of making
>even a simple abstraction like this?
No, I'm saying that while everyone involved may agree on the objective
facts, the relative importance of these facts varies greatly with
one's perspective. To call someone ignorant for disagreeing with one
on issues of relative importance is itself an ignorant thing to do.
Thomas F. Burdick
> On 27 Aug 2003 13:36:03 +0200, Nils Goesche <car...@cartan.de> wrote:
>
> >wallacet...@eircom.net (Russell Wallace) writes:
> >
> >> To a Common Lisp guy they may be, but to a Java guy they aren't.
> >
> >Why? Are you saying that Java Man's brain is not capable of making
> >even a simple abstraction like this?
>
> No, I'm saying that while everyone involved may agree on the objective
> facts, the relative importance of these facts varies greatly with
> one's perspective. To call someone ignorant for disagreeing with one
> on issues of relative importance is itself an ignorant thing to do.
You're arguing this so out of context, it's practically trolling. Go
back and look at the quote -- he was using the argument that Scheme is
small, to dismiss macros. The small/large division was the only
comparison being made, so I'd certainly hope everyone agrees it's
relevant. If not, they need to work on their reading comprehension.
Russell Wallace
F. Burdick) wrote:
>You're arguing this so out of context, it's practically trolling. Go
>back and look at the quote -- he was using the argument that Scheme is
>small, to dismiss macros. The small/large division was the only
>comparison being made, so I'd certainly hope everyone agrees it's
>relevant. If not, they need to work on their reading comprehension.
If you're going to accuse other people of lack of reading
comprehension - and come across like an obnoxious prick doing it, to
boot - it really helps to actually understand what you're talking
about. That way you'd look a lot less stupid. Try reading the quote
again, slowly this time. Hint: it didn't contain the words "Scheme is
small". Look instead for the word "general".
> ,' .\ / | No to Imperialist war |
> ,--' _,' | Wage class war! |
You do realize people like you are the first against the wall when
that advice gets followed?
Kenny Tilton
Russell Wallace wrote:
> ....Try reading the quote
> again, slowly this time. Hint: it didn't contain the words "Scheme is
> small". Look instead for the word "general".
OK, found it buried under "a small number": "In general, once [sic] can
contrast the Scheme-like philosophy of using a small number of very
>>>general<<< constructs, with the more mainstream approach of having a
great many highly specialized constructs,...".
Now what do I do?!
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Thomas F. Burdick
> > ,' .\ / | No to Imperialist war |
> > ,--' _,' | Wage class war! |
>
> You do realize people like you are the first against the wall when
> that advice gets followed?
Red-baiting almost always sheds light on the quality of one's argument.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
Russell Wallace
wrote:
>OK, found it buried under "a small number": "In general, once [sic] can
>contrast the Scheme-like philosophy of using a small number of very
> >>>general<<< constructs, with the more mainstream approach of having a
>great many highly specialized constructs,...".
That's the one. The guy who wrote that wasn't commenting on the
"batteries included" philosophy of Common Lisp and Java versus the
"batteries not included" philosophy of Scheme and C. He was commenting
on what is to most programmers the huge gulf that separates all
Lisp-family languages from practically everything else, namely Lisp's
adoption of a single, ultra-flexible syntactical form (the
s-expression) versus the fixed and relatively large catalog of
syntactical forms used by almost all other languages. (Remember the
context was the justification for omitting macros from languages like
Java.)
(Just in case this is perceived as Lisp-bashing that needs to be
defended against, note that I'm planning to use Lisp for my next
project precisely _because_ of this flexibility of syntax and the
code-is-data property it enables. Whether to use specifically Common
Lisp or Scheme is something I'll decide based on the available
implementations of each.)
John
> Ok, so on comp.lang.python we were having a discussion of Ruby vs.
> Python. Somehow, we got onto the topic of Macros. Personally I
> really like Macros, so I was defending the idea of Macros in Python.
> However a large group of people are diametrically opposed to Macros.
>
Part of what makes macroes usefull and powerfull in lisp is the simple
syntax tree.
The syntax tree in python is complex and incosistent.
So macroes in Lisp work fine while the syntax of python makes macroes
impractical.
This is one of the reasons I still prefer Lisp over, say, Ruby.
John
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Paul Tarvydas
> So macroes in Lisp work fine while the syntax of python makes macroes
> impractical.
> This is one of the reasons I still prefer Lisp over, say, Ruby.
Probably belabouring the point... let me point you at something like TXL
(www.txl.ca), which makes macros (source-to-source transformation)
practical for a wide variety of languages.
If one truly believed that macros were incredibly useful, then one could
embed TXL-like technology in one's language.
I think that the word "macro" has become an allergy-word due to peoples' bad
experiences in C and that's why the concept gets shut down without further
thought.
pt