Avoiding unintentional variable capture
Reini Urban
Of course I know "On Lisp" and the scheme macros which suffer from the
Lisp1 decision.
But reading the Tanksley-Joswig talk, Tanksley complaining about the
semantic problem with macros, I thought why not writing a compiler which
can automatically rename such captured vars in a new special form,
defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown
away then :)
No really, a decent compiler should be able to do the static analysis of
possible variable captures in special macros and rename/gensym them.
(Letting dynamic creation of such DEFSAFEMACRO's aside.)
I as developer really don't want to think about how to put this gensym
here and this gensym there. But since this is such an important issue, I
wonder if this wasn't detected/discussed before and why it cannot
happen.
Short theoretical counter-evidences appreciated.
Heck, Graham evem wrote a book about it. (and got rich later :)
Stalin even does dynamic analysis for its types, why not solve the
relatively simple capture problem?
Why an improved compiler?
A macro-macro could be used instead, to generate the gensym'ed macro as
well. On Lisp has such tricks, but only partly. Not the real thing.
But it would be simplier to add into a compiler IMHO. (I never wrote
one). It seems to be quite similar to lexical analysis.
Lisp1/Lisp2: Such a compiler could solve my (and scheme's) Lisp1 problem
as well.
The definition should be just a _semantical_ framework for the actual
definition produced by the compiler, avoiding capture -by vars. and in
Lisp1 by other conflicting names as well.
(define-safe list (list) ...)
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
William Tanksley
>Stupid subject line.
Grin.
>But reading the Tanksley-Joswig talk, Tanksley complaining about the
>semantic problem with macros, I thought why not writing a compiler which
>can automatically rename such captured vars in a new special form,
>defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown
>away then :)
No! Anaphor is a powerful thing, and any change to avoid its bad effects
would also destroy its good ones (and thus obsolete all macros).
Lisp doesn't need to be changed to avoid accidental symbol capture. All
you have to do is define and use a very simple macro, let's call it
"hygenic-let", which uses 'let' and 'gensym' to create new variables which
will shadow the old ones.
An example of its usage would be:
(defmacro duh (x y z)
(hygenic-let ((i 1) (j 2))
(do-things i x y z)
j))
Make sense? This has just declared i and j to be hygenic -- secretly,
it's replaced every use of i and j with a new gensym.
'On Lisp' defines this macro, IIRC, but I don't remember what it called it.
>No really, a decent compiler should be able to do the static analysis of
>possible variable captures in special macros and rename/gensym them.
>(Letting dynamic creation of such DEFSAFEMACRO's aside.)
No need -- Lisp already does this, with only a little work on the
implementor's part.
>Reini Urban
--
-William "Billy" Tanksley
Kent M Pitman
> But reading the Tanksley-Joswig talk, Tanksley complaining about the
> semantic problem with macros, I thought why not writing a compiler which
> can automatically rename such captured vars in a new special form,
> defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown
> away then :)
Macros are not generally unsafe in Lisp. They are only really
unsafe in Scheme, which has no package system and only one namespace.
The combined effect of those two design decisions makes the namespace
very crowded and virtually requires a hygienic macro system. Lisp
has used its simpler macro system with great success and very little
problem for many years and unintentional variable capture doesn't require
anything as sophisticated as a special defsafemacro.
This is a common misperception about Lisp which people carry in from
Scheem. People need to understand that problems always exist in a
context. Moving to a new context requires reevaluating the issues
in the new circumstances, not just assuming they carry over.
Johan Kullstam
> On Wed, 08 Sep 1999 20:10:23 GMT, Reini Urban wrote:
> >Stupid subject line.
>
> Grin.
>
> >But reading the Tanksley-Joswig talk, Tanksley complaining about the
> >semantic problem with macros, I thought why not writing a compiler which
> >can automatically rename such captured vars in a new special form,
> >defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown
> >away then :)
>
> No! Anaphor is a powerful thing, and any change to avoid its bad effects
> would also destroy its good ones (and thus obsolete all macros).
>
> Lisp doesn't need to be changed to avoid accidental symbol capture. All
> you have to do is define and use a very simple macro, let's call it
> "hygenic-let", which uses 'let' and 'gensym' to create new variables which
> will shadow the old ones.
>
> An example of its usage would be:
>
> (defmacro duh (x y z)
> (hygenic-let ((i 1) (j 2))
> (do-things i x y z)
> j))
>
> Make sense? This has just declared i and j to be hygenic -- secretly,
> it's replaced every use of i and j with a new gensym.
>
> 'On Lisp' defines this macro, IIRC, but I don't remember what it
> called it.
graham called it WITH-GENSYMS
(defmacro with-gensyms (syms &body body)
`(let ,(mapcar #'(lambda (s)
`(,s (gensym)))
syms)
,@body))
here's an example of its use
(defmacro allf (val &rest args)
(with-gensyms (gval)
`(let ((,gval ,val))
(setf ,@(mapcan #'(lambda (a) (list a gval))
args)))))
i find WITH-GENSYMS to be highly useful.
> >No really, a decent compiler should be able to do the static analysis of
> >possible variable captures in special macros and rename/gensym them.
> >(Letting dynamic creation of such DEFSAFEMACRO's aside.)
nod. INLINE is supposed to do this (no comments about any particular
implementations). this also barring the effect of SETF not
escaping the scope of the function problem.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Dorai Sitaram
Kent M Pitman <pit...@world.std.com> wrote:
>
>Macros are not generally unsafe in Lisp. They are only really
>unsafe in Scheme, which has no package system and only one namespace.
>The combined effect of those two design decisions makes the namespace
>very crowded and virtually requires a hygienic macro system. Lisp
>has used its simpler macro system with great success and very little
>problem for many years and unintentional variable capture doesn't require
>anything as sophisticated as a special defsafemacro.
>
>This is a common misperception about Lisp which people carry in from
>Scheem. People need to understand that problems always exist in a
>context. Moving to a new context requires reevaluating the issues
>in the new circumstances, not just assuming they carry over.
Since you talk so glibly about common misperceptions...
Your first sentence is right on. After that you
descend into flat out, unsubstantiated innuendo. There
is no basis for your claim that choosing a single
namespace condemns a language to requiring a hygienic
macro system.
(1) The problems that hygiene solves are not eliminated
by multiple namespaces; and (2) the standard ways used
to solve hygiene issues in a non-hygienic
multi-namespace environment work equally well in a
non-hygienic single-namespace environment.
It is OK to have an antipathy toward Scheme. Just
don't cheat yourself into having an antipathy toward
truth in the process.
--d
Kent M Pitman
> In article <sfw671l...@world.std.com>,
> Kent M Pitman <pit...@world.std.com> wrote:
> >
> >Macros are not generally unsafe in Lisp. They are only really
> >unsafe in Scheme, which has no package system and only one namespace.
>
> Since you talk so glibly about common misperceptions...
>
> Your first sentence is right on. After that you
> descend into flat out, unsubstantiated innuendo.
No, I'm just citing the specific wisdom of the Scheme community, who found
it desperately important to have hygeinic macros. I don't have a strong
opinion on this one way or another and probably would have preferred to use
Lisp-like macros in Scheme rather than go to all that complexity of syntactic
closures and/or painting.
> There is no basis for your claim that choosing a single namespace
> condemns a language to requiring a hygienic macro system.
I made no such sweeping claim. I merely made a few brief remarks intended
to dislodge the quite-common misperception that Lisp is broken for not
having hygeine in its macro system. Any additional references I made were
primarily to ground my reaction in the sociological mess which I didn't
create but have merely observed wherein many in the Scheme community are
in a virtual frenzy from time to time over how broken they perceive CL to
be on this point even though many of those holding that opinion appear not
to use CL often enough to have a useful opinion.
> (1) The problems that hygiene solves are not eliminated
> by multiple namespaces; and (2) the standard ways used
> to solve hygiene issues in a non-hygienic
> multi-namespace environment work equally well in a
> non-hygienic single-namespace environment.
>
> It is OK to have an antipathy toward Scheme. Just
> don't cheat yourself into having an antipathy toward
> truth in the process.
I program in Scheme daily these days, by the way. I don't have antipathy
toward it. It's just a tool like any other. My remarks were made in a
specific context to address a specific remark. I really don't have the
energy for this discussion. My goal was to establish that there were two
sides to this discussion, not to win a discussion. No amount of your
trying to convince me there are two sides to this discussion is going
to dissuade me from thinking there are.
Marco Antoniotti
ds...@bunny.gte.com (Dorai Sitaram) writes:
> It is OK to have an antipathy toward Scheme. Just
> don't cheat yourself into having an antipathy toward
> truth in the process.
A simple truth. Scheme does not yet have DEFSTRUCT (or DEFINE-RECORD,
or whatever).
Another simple inference (most likely historically true). DEFSTRUCT
(or similar) is not in Scheme (yet) because of the lack of a macro
system in the early versions of RxRS.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Erik Naggum
| graham called it WITH-GENSYMS
I have found COPY-SYMBOL to be superior to GENSYM in that the symbols
produced have understandable names, which helps a lot when looking at the
expansion and at the produced code.
#:Erik
--
it's election time in Norway. explains everything, doesn't it?
Iver Odin Kvello
KMP> No, I'm just citing the specific wisdom of the Scheme
KMP> community, who found it desperately important to have
KMP> hygeinic macros. I don't have a strong opinion on this one
KMP> way or another and probably would have preferred to use
KMP> Lisp-like macros in Scheme rather than go to all that
KMP> complexity of syntactic closures and/or painting.
Actually, I'm not really sure this (apparently plausible) reason for
wanting hygienic macros really ever were part of the motivation for adding
them. I base this on two things:
1. I can find no reference to this 'namespace crowding problem' in the
literature, nor in the RRRS-mailinglist, nor in any contemporary
archived public fora. I might have missed it of course, but I were
able to find other reasons, namely the ordinary ones against macros
(makes-programs-difficult-to-read and all that), the problem of name
capture alluded to as a well-known problem *outside* of Scheme, and
perhaps the more culturally Scheme-specific one of full, traditional
macros making it harder to prove things about Scheme programs. In
addition, there seems to have been a strong feeling that hygienic
macros were The Right Thing in a sense, "correct" and so on.
2. It hasn't been all that common to actually implement a hygienic
macro system in Scheme implementations, so in fact quite a lot of
Scheme code has been written using traditional macros using gensym and
so on to manually ensure hygiene. And in fact this seems to work quite
allright even in a Lisp-1.
I think it is also important to remember that Scheme-style hygienic
macros, and not least the system actually added to the R5RS is pretty
different from DEFMACRO in other ways than hygiene - It's a limited
system for doing certain simple syntactic abstractions in a "correct"
way (meaning at least hygienic) in a presumably easy-to-read and write
manner. Traditional macros do this job too, but fundamentally they are
just lisp programs writing lisp programs - far simpler and with far
more power. And there is space for many kinds of systems between these
two. I think the differences, effective and philosophical, between
these systems are a lot more complicated than what can be generated
from a Lisp-1 decision.
--
(define (cthulhu_fhthagn) ; Iver Odin Kvello, iv...@hfstud.uio.no
(call/cthulhu (lambda (destroy) ; Lambda, the Ultimate Horror
(if (stars-are-right? (now)) (destroy 'everything) (cthulhu_fhtagn)))))
Iver Odin Kvello
Marco> Another simple inference (most likely historically true).
Marco> DEFSTRUCT (or similar) is not in Scheme (yet) because of
Marco> the lack of a macro system in the early versions of RxRS.
No, this is most definitely not true. There are a lot of material
about this available on-line, and macros had nothing to do about it.
They weren't added because it were impossible to reach a consensus on
syntax and semantics. There were many small-but-important points
argued - I can't even begin to summarize. But SRFI-9 just recently
became final; it's a defstruct thing, and if you read the discussion
surrounding that one, you can get a feel of it.
William Deakin
> "On Lisp" could be thrown away then :)
If you are, can I have your copy? I will pay the postage (of course) ;)
:-) will
Founding member of the Society for the Prevention of Cruelty to Unwanted and
Wayward Lisp Texts (On LISP Chapter).
Kent M Pitman
> >>>>> "KMP" == Kent M Pitman <pit...@world.std.com> writes:
>
> KMP> No, I'm just citing the specific wisdom of the Scheme
> KMP> community, who found it desperately important to have
> KMP> hygeinic macros. I don't have a strong opinion on this one
> KMP> way or another and probably would have preferred to use
> KMP> Lisp-like macros in Scheme rather than go to all that
> KMP> complexity of syntactic closures and/or painting.
>
> Actually, I'm not really sure this (apparently plausible) reason for
> wanting hygienic macros really ever were part of the motivation for adding
> them. I base this on two things:
>
> 1. I can find no reference to this 'namespace crowding problem' in the
> literature, nor in the RRRS-mailinglist, nor in any contemporary
> archived public fora.
I was a Scheme implementor in 1981, working with Jonathan Rees on
jumpstarting the T project at Yale. I did the initial high-level
design of T, including a prototype written in Maclisp, while Jonathan
worked on compiler things. I don't rely on publications for this
because it was personal experience. I didn't publish so may not be
able to to document it to your satisfaction, but I'm quite sure I was
working on a "syntactic closure" mechanism of my own that year. I
didn't finish it totally but had the basic concepts worked out in my
head. I had it on my "potential paper topics" list for a while until
Gene Kohlbecker came up with the painting thing (which I detested for
philosophical reasons, in spite of the elegance some people see in
it); fortunately, Alan Bawden (I think it was him) had the alternative
syntactic closure concept which at least expressed the ideas I was
wishing for in a way that got the concepts onto the record (i.e.,
there were papers written). No, I was not on the paper--it was
independent work on his part. It's fine if you simply don't believe
any of this as a result of my inability to document it. But the fact
is that there was a huge soup of language design activity going on,
lots of which does not appear in The Literature, and you SHOULD
believe that. Lots of people had lots of good ideas they will never
get credit for. I also recall at least one in-person meeting with
Sussman on this macro issue and numerous other major issues. We were
trying to figure out various ways the Scheme design should proceed.
(It was involvement in things like this at that time that is the
reason I ended up going to Scheme design meetings, and why I am one of
the now-two-dozenish authors of the Scheme spec.)
I do have a lot of paper records of the things we dealt with at the
time, and it's *possible* that this macro busines is in the records.
They're not published, buta at this point radio carbon dating would
probably be able to verify their authenticity. (sigh) However, I'm not
motivated to check right now. At some point I hope to scan all that
stuff because it's old paper and at some risk of becoming fragile.
> I think it is also important to remember that Scheme-style hygienic
> macros, and not least the system actually added to the R5RS is pretty
> different from DEFMACRO in other ways than hygiene
I can't tell you how I tire of having people tell me about how I have
to remember that Scheme is different than Lisp. I do know this. I
have lived the entire history and helped once in a while even to
influence it. I do know. I promise. I may have different opinions
than some in the Scheme community, but I am not an idiot.
> I think the differences, effective and philosophical, between
> these systems are a lot more complicated than what can be generated
> from a Lisp-1 decision.
I actually couldn't understand the part after the "than" here well enough
to respond to this, but maybe it's just as well.
My point was exactly and only that there were two materially interesting
contributing factors to the heightened interest in Scheme over CL in
the area of hygiene: namespace and absence of symbol packages (in favor of
capturing modules entirely by lexical scoping). [I was sloppily blurring
the fact of the deliberately ambiguous specification of Scheme in a way
that makes it impossible to tell if it's defined by read syntax or
by cons'd symbols/lists as yet another aspect of the packaging issue, but
some might say that should be separated into a third reason, since
explaining "gensyms", if a language has them, is hard in a language
defined by its textual syntax, which some want Scheme to be.] I did not
say any of these issues force the case in all languages with these
properties; I said they did [politically, not scientifically] lead to
the presence of hygiene in Scheme but not in CL, and I said I didn't
think it was a bug in either case because the circumstances in each
case are different. Whatever other sweeping things people have inferred
from what I said seem to me to be inappropriately construed.
Dorai Sitaram
Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> wrote:
>
>ds...@bunny.gte.com (Dorai Sitaram) writes:
>
>> It is OK to have an antipathy toward Scheme. Just
>> don't cheat yourself into having an antipathy toward
>> truth in the process.
>
>A simple truth. Scheme does not yet have DEFSTRUCT (or DEFINE-RECORD,
>or whatever).
>
>(or similar) is not in Scheme (yet) because of the lack of a macro
>system in the early versions of RxRS.
Huh? What do you think I said, Mario?
--d
Marco Antoniotti
Iver Odin Kvello <iv...@hfstud.uio.no> writes:
> >>>>> "Marco" == Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> writes:
>
> Marco> Another simple inference (most likely historically true).
> Marco> DEFSTRUCT (or similar) is not in Scheme (yet) because of
> Marco> the lack of a macro system in the early versions of RxRS.
>
> No, this is most definitely not true. There are a lot of material
> about this available on-line, and macros had nothing to do about it.
It ain't in RxRS => it ain't in Scheme.
Note that there are thousands of potential CL variants of DEFSTRUCT as
well.
> They weren't added because it were impossible to reach a consensus on
> syntax and semantics. There were many small-but-important points
> argued - I can't even begin to summarize. But SRFI-9 just recently
> became final; it's a defstruct thing, and if you read the discussion
> surrounding that one, you can get a feel of it.
The only feeling I get is that it is now September 1999 and DEFSTRUCT
was in CLtL1 in 1984. That's 15 years ago!
Iver Odin Kvello
Marco> DEFSTRUCT (or similar) is not in Scheme (yet) because of
Marco> the lack of a macro system in the early versions of RxRS.
>> No, this is most definitely not true. There are a lot of
>> material about this available on-line, and macros had nothing
>> to do about it.
MA> It ain't in RxRS => it ain't in Scheme.
True, but that's not what I meant: There's a lot of material available
*about why DEFSTRUCT (or similar) isn't in the RxRS*, and the lack of
macros had nothing to do with *that*.
>> They weren't added because it were impossible to reach a
>> consensus on syntax and semantics. There were many
>> small-but-important points argued - I can't even begin to
>> summarize. But SRFI-9 just recently became final; it's a
>> defstruct thing, and if you read the discussion surrounding
>> that one, you can get a feel of it.
MA> The only feeling I get is that it is now September 1999 and
MA> DEFSTRUCT was in CLtL1 in 1984. That's 15 years ago!
Look, I was just trying to be helpful in case you actually were interested
in the truth of your hypothesis. It's quite obvious that Scheme isn't as
well-developed as it should have been by now, I'm not disputing
that. I don't even care much about it, since I wouldn't actually use
Scheme as long as I have a Common Lisp available.
Dorai Sitaram
Kent M Pitman <pit...@world.std.com> wrote:
>I merely made a few brief remarks intended
>to dislodge the quite-common misperception that Lisp is broken for not
>having hygeine in its macro system. Any additional references I made were
>primarily to ground my reaction in the sociological mess which I didn't
>create but have merely observed wherein many in the Scheme community are
>in a virtual frenzy from time to time over how broken they perceive CL to
>be on this point even though many of those holding that opinion appear not
>to use CL often enough to have a useful opinion.
>
>> don't cheat yourself into having an antipathy toward
>> truth in the process.
>
>toward it. It's just a tool like any other. My remarks were made in a
>specific context to address a specific remark. I really don't have the
>energy for this discussion. My goal was to establish that there were two
>sides to this discussion, not to win a discussion. No amount of your
>trying to convince me there are two sides to this discussion is going
>to dissuade me from thinking there are.
Well, all right. FWIW, I am sorry you had all those
harrowing experiences with the Scheme community. What
comes across very clearly in your response is that you
have this antipathy toward the Scheme community, if not
toward Scheme per se. Either kind of antipathy is OK.
I still think it is unfortunate to be enraged or
seduced into silly untruths because of that. Fighting
fire with fire really works only for the Fire
Department. Out here it only adds to that
"sociological mess" that you feel burned by.
--d
Reini Urban
>Reini Urban wrote:
>> "On Lisp" could be thrown away then :)
>
>If you are, can I have your copy? I will pay the postage (of course) ;)
No! "On Lisp" was one the most expensive books I bought recently.
(>$60 at amazon, now it is at $49)
I don't know why, I feel PAIP or SICP should be more expensive.
(hmm, quick-checked it: $59 and $65, this is okay)
with-gensyms and macros at all are not really the things I love.
What I don't like with user-defined gensyms in macros is
unreadability, hard to write and somewhat knowing in advance
which vars can get captured. (really every?)
Similar to the black art of backquoting.
Of course you can gensym all your vars in the macro, but this might
be a waste of resources (and performance). The compiler should
know which vars will be affected and wrap the gensym part around
this only.
Besides this I really dislike the syntax of gensym-ed protection
wrappers. too low-level for me.
That's why I thought it should be done automatically. hmm...
Not easy for dynamic lisps like elisp or autolisp.
The scheme syntax for the hygienic macros is btw. really nice.
This might be a good thinggy for our AutoLISP users.
But it is too high-level. Not too easy to explain.
I wanted something in between.
Looks like that I have to patch a CCL copy just for
fun, to see if it makes sense to me.
--
Reini
(my local newsfeed is a mess nowadays.
10-20 hours for this...
news.tu-graz.ac.at dies a slow death.)
Raymond Toy
Reini> William Deakin <wi...@pindar.com> wrote:
>> Reini Urban wrote:
>>> "On Lisp" could be thrown away then :)
>>
>> If you are, can I have your copy? I will pay the postage (of course) ;)
Reini> No! "On Lisp" was one the most expensive books I bought recently.
Reini> (>$60 at amazon, now it is at $49)
And worth every penny! I learned a lot from reading it, and, to me,
this book really shows you what separates Lisp from all the other
languages out there.
Reini> What I don't like with user-defined gensyms in macros is
Reini> unreadability, hard to write and somewhat knowing in
Reini> advance which vars can get captured. (really every?)
Reini> Similar to the black art of backquoting. Of course you can
Reini> gensym all your vars in the macro, but this might be a
Reini> waste of resources (and performance). The compiler should
Reini> know which vars will be affected and wrap the gensym part
Reini> around this only.
If your compiler is smart enough to know when NOT to gensym something,
then surely it would be smart enough not to waste resources and
performance when you DO gensym everything.
How would you tell such a compiler that you really do want variable
capture?
Ray
Kent M Pitman
> FWIW, I am sorry you had all those harrowing experiences with the
> Scheme community. What comes across very clearly in your response
> is that you have this antipathy toward the Scheme community, if not
> toward Scheme per se. Either kind of antipathy is OK.
I have no antipathy for Scheme. It is simply a language. It makes some
decisions I like and some I consider questionable, but always in context
of its stated goals, and you would probably be surprised which things
I like and don't like about its set of choices.
I have no antipathy for the Scheme community per se, but I HAVE had a
large number of run-ins with zealots who appear "programmed" (for want
of a better word: like the guys who used to harrass people in airports
about various religions) to attack Common Lisp for reasons that make
no sense but that they hang onto like attack dogs to an exposed limb.
There are certain number of pet rants they have, and this is one of them.
And I feel it important to say in very strong terms that "there is another
side" because I have encountered a large number of people over the years
who have concluded from the simple absence of conflict on the matter
that there must BE no other side. They have said it to me just
that plainly. "Oh, I never realized there was any other point of view
because people say this kind of thing all the time and no one ever
contradicts them." I would have hoped they would use their brain or ask
someone before forming such a conclusion, but given that it is my belief
that in the modern conflict-oriented world to be silent in the face of
babble is somehow to give credence to the babble, I do not always stay
silent or seek a polite venue, regardless of how you or even I might feel
about whether that escalates the flames, because the people who are
watching for fights are not watching the polite venues and the soul of
the onlookers is lost on the battleground where the false statements
are made.
I also had to actively part company with the Scheme community because I
lost track of the number of actively and intentionally offensive statements
made by Scheme people about Common Lisp in the kind of mean-spirited way
that racist and sexist comments used to be the order of the day in
certain communities. Words spoken in very formal venues, like in paper
talks at conferences, where people said things like "we didn't want to
do it that way because that would have been like Common Lisp and we all
know how awful that is" and stuff like that. Lots of times Common Lisp
being used sort of like "bottom" in mathematics as a kind of all-purpose
infectious agent the mere association with which would render something
bad. I have been to standards meetings where I couldn't distribute a
photocopied page from the ANSI spec to illustrate a point because formal
representatives of other nations had the discourtesy to tell me to my face
that they would have nothing to do with Common Lisp because it was so
awful, and who would not accept that any isolated sub-piece of the document
could be viewed in isolation without somehow infecting their mode of thought.
I have been round and round with various people in the Scheme community
about the active hate that people express for "iteration" in the form even
of the simple (keyword-free) LOOP because people have failed to learn the
important lesson of Scheme which is that there should be "choices", and
instead have learned the dogma which is that "loop must be rejected and
tail recursion is the only way". I have been round and round about why
packages are a total loss (they say) and only [lexical] modules have any
value (they say). I have been round and round about why lisp1 is good and
all other namespace arrangements are bad. And, as here, I have heard
people assumes this idiotic term "hygiene" to mean that there is no possible
way for programs in other languages to ever work. And for each of these,
I have a short fuse because while there are certainly points on both sides
of the arguments on these--they are complex issues--I don't see the Scheme
community investing time in making sure people know both sides.
I consider the essential, fundamental difference between the Scheme
and CL community as captured in the statement: "There are two kinds of
people in the world: people who think there are two kinds of people
and people who don't." The thing that I value the most about CL and
its community is its ability to embrace multiple concepts and multiple
ways to think about things; and the thing I find the most troubling
about Scheme and its community is that a language which started out
and is technically designed to support such a wide variety of options
has somehow bred a community which so often in practice leaves me
engaged in conversations with representatives of it who seem concerned
about cutting off options rather than expanding them. I so rarely
hear the successful resolution of any discussion with someone from
that community be "you're right, there are two ways to look at this"
that I have given up trying. I never want people to have only one way
to look at things and I don't go into arguments assuming I will change
people to the CL way--only to expand their concepts to include CL's ways
as a possible and legitimate alternative. It is extraordinarily rare
that I am shown the same courtesy by the other camp. It does happen;
the world is made up of individuals and there are some very nice and
open-minded individuals out there who I do not mean to catch in this
broad-brush analysis. But often it does not, and that's a fact. One
I wish I knew better how to deal with.
You are right, yes. I have had some remarkably bad experiences that I take
very personally between these communities. As a rule, I stay clear of
the Scheme community socially other than my participation on the Scheme
design committees, which is about all the association I can stand.
And I take it personally when I perceive (rightly or wrongly; I do not
claim to be infallible) that their evangelists are afoot blindly trying to
solve problems that they perceive we have without first verifying that.
The tip-off in this case being a generic discussion started on a known
religious issue without citing a specific code example where the issue
was a problem, thus cutting of the ability to suggest a technical solution
that might head off the abstract/religious discussion.
> I still
> think it is unfortunate to be enraged or seduced into silly untruths
> because of that. Fighting fire with fire really works only for the
> Fire Department. Out here it only adds to that "sociological mess"
> that you feel burned by.
Perhaps so. I spent years just ignoring the problem, though, and that
did not help. I also have devoted my whole life to educating the
public on important issues. But that hasn't worked as well as it might
either. Some solutions are imperfect no matter how you go at them.
We do what we can.
William Deakin
Raymond Toy wrote:
> How would you tell such a compiler that you really do want variable capture?
what about (declare (capturable mungo mongo midge))? ;)
:-) will
Marco Antoniotti
Iver Odin Kvello <iv...@hfstud.uio.no> writes:
> Marco> DEFSTRUCT (or similar) is not in Scheme (yet) because of
> Marco> the lack of a macro system in the early versions of RxRS.
> >> No, this is most definitely not true. There are a lot of
> >> material about this available on-line, and macros had nothing
> >> to do about it.
>
> MA> It ain't in RxRS => it ain't in Scheme.
>
> True, but that's not what I meant: There's a lot of material available
> *about why DEFSTRUCT (or similar) isn't in the RxRS*, and the lack of
> macros had nothing to do with *that*.
Point taken. I was implying that if Scheme had had decent macros
since the beginning, then, more experimentation would have happened,
hence DEFSTRUCT or similar would have already been included in RxRS.
>
> >> They weren't added because it were impossible to reach a
> >> consensus on syntax and semantics. There were many
> >> small-but-important points argued - I can't even begin to
> >> summarize. But SRFI-9 just recently became final; it's a
> >> defstruct thing, and if you read the discussion surrounding
> >> that one, you can get a feel of it.
>
> MA> The only feeling I get is that it is now September 1999 and
> MA> DEFSTRUCT was in CLtL1 in 1984. That's 15 years ago!
>
> Look, I was just trying to be helpful in case you actually were interested
> in the truth of your hypothesis. It's quite obvious that Scheme isn't as
> well-developed as it should have been by now, I'm not disputing
> that. I don't even care much about it, since I wouldn't actually use
> Scheme as long as I have a Common Lisp available.
Apologies for my rant. I should have not been so harsh. After all I
am programming mostly in Java now :}
Tim Bradshaw
> What I don't like with user-defined gensyms in macros is
> unreadability, hard to write and somewhat knowing in advance
> which vars can get captured. (really every?)
I don't see why it's hard to know this. If the macro expands into
something that binds variables, you need to make sure those variables
have unique names, unless you intend them to be visible in the
expansion (which is surprisingly often the case).
> Of course you can gensym all your vars in the macro, but this might
> be a waste of resources (and performance).
I can't imagine a realistic case where it has any significant impact
on either, unless you have a really slow compiler.
--tim
William Deakin
> William Deakin <wi...@pindar.com> wrote:
> >Reini Urban wrote:
> >> "On Lisp" could be thrown away then :)
> >
> >If you are, can I have your copy? I will pay the postage (of course) ;)
>
> No! "On Lisp" was one the most expensive books I bought recently.
But was it worth it? I was concerned that you would be thowing away such an
expensive (and valuable) book and that I could find a good home for such a
book. I like books. My to my wifes despair.
I'm trying to think what the most expensive book that I've bought recently
and it is probably PAIP (£36.40) and not 'On LISP' (£31.50). But I would pay
£40 or more for "On LISP"
> What I don't like with user-defined gensyms in macros is unreadability,
> hard to write and somewhat knowing in advance which vars can get captured.
> (really every?)
Write a macro to do this for you. :)
> Besides this I really dislike the syntax of gensym-ed protection wrappers.
> too low-level for me.
Sorry? :|
> That's why I thought it should be done automatically. hmm... Not easy for
> dynamic lisps like elisp or autolisp.
Yup. But does that make CL wrong? Maybe elisp or autolisp should be
lexically scoped. Join the 90's &c :)
> The scheme syntax for the hygienic macros is btw. really nice.
I'm sure it is but I am no great shakes as a CL programmer and am even worse
at scheme. :( 'Whereof one does not know thereof one should not speak'
> Looks like that I have to patch a CCL copy just for fun, to see if it
> makes sense to me.
What is a CCL?
> (my local newsfeed is a mess nowadays. 10-20 hours for this...
Bad news :(
Cheers,
:-) will
Patrick A. O'Donnell
> Kent M Pitman <pit...@world.std.com> wrote:
> >I merely made a few brief remarks intended
> >to dislodge the quite-common misperception that Lisp is broken for not
> >having hygeine in its macro system.
> >I program in Scheme daily these days, by the way. I don't have antipathy
> >toward it. It's just a tool like any other. My remarks were made in a
> >specific context to address a specific remark.
>
> harrowing experiences with the Scheme community. What
> comes across very clearly in your response is that you
> have this antipathy toward the Scheme community, if not
> toward Scheme per se.
I simply cannot let this go by unchallenged. Dorai claims to be
defending "truth", yet mostly writes flat out, unsubstantiated
innuendo and ad hominem attacks. I certainly see no "clear antipathy"
toward either Scheme or the Scheme community in any of Kent's
writings, which I've followed for many years. I do see much
thoughtful comment about choices made by both the Scheme and the CL
communities, and the consequences of those choices from the point of
view of one who is both a language designer and a language user. I,
for one, appreciate the view into the processes that created both
these languages.
- Patrick O'Donnell
p...@alum.mit.edu
Reini Urban
>If your compiler is smart enough to know when NOT to gensym something,
>then surely it would be smart enough not to waste resources and
>performance when you DO gensym everything.
>
>capture?
glad you asked that: then I would use a function, not a macro.
functions should have distinctive variables.
macros just placeholders, they should not infect others.
(100% unintentional)
using macros just not to evaluate one of its arguments is lame.
lambdas are better.
Stig Hemmer
> Raymond Toy wrote:
> >How would you tell such a compiler that you really do want variable
> >capture?
>
> glad you asked that: then I would use a function, not a macro.
OK, write a function which allows you write code more or less like
this:
(asetf (second list) (+ it 7))
The first parameter is a _place_, and the the second is an expression
giving the new value for that place, where the the variable IT is
captured to the old value of that place.
This example is from Paul Grahams book "On Lisp", by the way.
Stig Hemmer,
Jack of a Few Trades.
Erik Naggum
| Well, all right. FWIW, I am sorry you had all those harrowing
| experiences with the Scheme community. What comes across very clearly in
| your response is that you have this antipathy toward the Scheme
| I still think it is unfortunate to be enraged or seduced into silly
| untruths because of that. Fighting fire with fire really works only for
| the Fire Department. Out here it only adds to that "sociological mess"
| that you feel burned by.
excuse me, but why should I feel any better about Scheme, now? you
attack one of the most knowledgeable persons in _both_ communities for no
reason at all. is this _another_ instance of "political correctness"?
tell you what: I want to write nice, working programs that don't take
forever and to use as much of the legacy of mankind as possible in the
process. that's why I can't stand Scheme, which makes me feel like I
have been given exquisitely shaped flint stones and a beautifully
prepared coat made from a bear's hide, and then I have to re-invent
everything from there, which will neither be exquisite nor beauitiful
because I don't have 40,000 years to reinvent everything from where
Scheme left us in anything but rough ways. since Scheme people tend to
be extraordinarily proud of their hand-made bear coats and swing flint
stones like no one has ever seen and then challenge everyone they meet to
compete with them on such terms, especially Common Lisp people, I also
find little reason to frequent Scheme communities. when you arrive with
your own neanderthal attitude, Dorai, I tend to think that Scheme people
should be left alone, possibly relocated to a reservation, but let's make
sure we don't leave any metal ores nearby. there's no telling what would
happen if the Scheme community discovered bronze, or god forbid, iron.
but at least you're _incredibly_ hygienic and elegant, and I, too, admire
your fine flint stones, as long as I don't have to use them for anything.
Dorai Sitaram
OK, I guess you don't have an antipathy to the Scheme
community after all. :->
I wasn't asking you to be polite or not to flame. I
was asking you not to contribute to misunderstandings,
especially since you seem dedicated to removing them.
That's all.
I sense an attempt ("this is one of them", "two sides",
etc., etc.) to locate me in your standard catalog of
obstreperous rants by the Scheme community. If you are
not, I am grateful. I have already twice expressed my
dignified sympathy, and I frankly don't know what else
anybody can do when faced with this kind of extended
regurgitation of grief.
If, on the other hand, you are indeed locating me in
that noisome catalog of yours, at least there is some
comedy value to it. Nothing in my two articles can or
should be taken as a brief for Scheme in general or
hygienic macro systems in particular. Indeed, I quite
agree with you that developments in Scheme have made it
seem to some that hygienic macro systems are necessary
when they aren't really. I am just saying that having
one or two or many namespaces has no valid bearing on
which way one chooses to jump on the hygiene issue.
That, it would appear, is our only disagreement, or
maybe even not -- I am fast losing track of what you're
trying to say because you are getting way too
discursive.
--d
Erik Naggum
| using macros just not to evaluate one of its arguments is lame.
| lambdas are better.
then why don't you just program in Scheme? sometimes, I think the Lisp1
vs Lispn thing really _is_ about doing things one way or one of n ways.
what I really _don't_ understand is why Scheme freaks need to _prove_
Kent's points. it would seem much more rational to work very hard to
_disprove_ all his claims.
Kent M Pitman
> Raymond Toy wrote:
>
> > How would you tell such a compiler that you really do
> > want variable capture?
>
> what about (declare (capturable mungo mongo midge))? ;)
This would get my vote (if I thought the compiler had to be told
anything at all; as I've said, I'm not much of a mind that CL needs
hygiene but if it did, this would be a good way to specify thing).
A principle of language design that I endorse generally is that the
number of words you should have to say in order to communicate an
idea to the compiler should usually be about the same as you'd have
to say to someone over the phone or out loud to someone over dinner
in order to unambiguously communicate the same concept. To the extent
that you have to say materially more, it's often a cue that the
language designers have not done their job very well.
Although it's not a "language" per se, I have to say that the typical
verbiage you have to say to C++ (and most other languages) to get an
"object foothold" in CORBA is a good example of someplace where the
total number of words is hugely more than the number of words that
should be required. For some reason, little boilerplate pieces of code
like this seem to get turned into templates to be pasted in by programmers
of other language, and reveled in, rather than as so often in Lisp,
turned into macro expansions never to be seen again by humans. I don't
know why that is, but I often liken it to the trappings of chemical
addiction, where people are said to really get into the whole business
of preparing their fix as much as the actual actual taking of the drug
(whether it be opening the box of cigarettes and tapping it just so and
smelling it and so on, or whatever more elaborate thing for other drugs).
People are just creatures of habit and seem to gravitate toward systems
that provide them with mounds of predictable if drugerous business.
I dunno--maybe fighting the monotony that other systems serves up just
means users spend their life forever unpredictably stressed by new
technologies and maybe and we shouldn't fight it and should just let
them mire themselves in familiar, if monotonous, drudgery. But for
some reason I always focus on the idea of digging out of those
monotonous activities to find the new monotonous activities that await
once you get used to what's beyond...
Kent M Pitman
> I wasn't asking you to be polite or not to flame. I
> was asking you not to contribute to misunderstandings,
If you go back and re-read the conversation, I think you will see I
attacked no one. It's possible that your gripe is that in fact I did
attack no one since then that person would be morally empowered to
defend him or herself. However, I was responding only in kind to a
prior message which spoke about a general problem without specifics as
well, and I was doing my best to speak at the level of abstraction
already introduced and in the context already introduced.
Looking over my original message, the only statement I can think of
which I made which might be controversial was this one, which you
chose to respond to by attacking me pesonally rather than by merely
addressing the technical statement I made:
kmp> They are only really unsafe in Scheme, which has no package
kmp> system and only one namespace.
In defense of this remark, my use of the word "unsafe" was merely
following in the same literature that the Scheme community has used
this term in macros. There is a technical sense in which "unsafe"
means "capable of accidental capture" and that's a true and defensible
claim. If you want to add additional remarks saying that you have other
experiences, you're welcome to, but don't say I'm contributing to
confusion merely by restating the problem in a way that is faithful
to the original statement of the problem by the community that originally
established the issue. Further, it is true that Scheme has no package
system--it has a module system. And it is, like it or not, a common
oversight by people from the Scheme community who are unused to the package
system to say you can't write a macro that will avoid capture problems
when in fact, it's trivial to write a great many macros that will avoid
this if you just have either GENSYM or else MAKE-PACKAGE and INTERN.
So I don't see how I was contributing to a confusion by saying this.
The remainder of my message aws:
kmp> Macros are not generally unsafe in Lisp.
This statement is true and supported by lots of actual practice.
It does not, in my opinion, contribute to any misperception or confusion.
kmp> Lisp has used its simpler macro system with great success and
kmp> very little problem for many years and unintentional variable
kmp> capture doesn't require anything as sophisticated as a special
kmp> defsafemacro.
This statement also seems true to me even in hindsight.
kmp> This is a common misperception about Lisp which people carry
kmp> in from Scheem.
This statement seems true to me. It is a common misperception.
I wanted, as I often do, to take the incident of this message to
highlight the issue so that people could watch for it and catch it
when they see it rather than let it go by. I don't see how watching
for something makes for any confusion or misperception. I have a lot
of rules that say to "watch for something" in my head; that doesn't
mean I take an explicit action upon seeing them--I'm not advocating
dogma here. I'm advocating kicking this out to "conscious thought"
and not working on "autopilot" when statements of this kind are seen.
kmp> People need to understand that problems always exist in a
kmp> context.
It's hard to see how this contributes to a misperception or confusion.
kmp> Moving to a new context requires reevaluating the issues
kmp> in the new circumstances, not just assuming they carry over.
Ditto.
That concludes the entirety of my message which you chose to single out
an request I ""not [...] contribute to misunderstandings" with. I stand
by my claim that I did not. And further I stand by my claim that if there
was or ever is a misunderstanding in what I say, the right thing is simply
to address it at the appropriate technical level. I think I have an
established record of acknolwedging errors and confusions in what I've said,
or even of acknowledging legitimate points of view that I happen not to
agree with. I see no reason to get personal.
> especially since you seem dedicated to removing them.
I am dedicated to identifying them. Removing them seems to me like
fixing the "delete bug"--I don't have pointer access to really do it,
so why try?
> That's all.
>
> I sense an attempt ("this is one of them", "two sides",
> etc., etc.) to locate me in your standard catalog of
> obstreperous rants by the Scheme community.
I did not originally locate you in anything. The reply was originally
to Reini and the subject of the sentence in question was the idea, not
the community. I did not attribute the idea to everyone in the community,
I said the origin of the offending idea was the community. Communities
are large and pluralistic; no idea that is "of them" is "of every
individual within them". Nevertheless, it can be useful to understand
the reason for a confusion, and since the reason for this particular
confusion (about hygiene) is based in specific technical details of the
things those people do every day (they really do play with single
namespaces and they really do play with lexicality a lot), it seemed
appropriate to mention the context in order to support my real point which
was that context can influence one's perception of reality. And that is
a point I don't want to detract from in this long discussion of what is
politically right and wrong to say because it hurts someone's feelings
who I never said I wanted to hurt.
> If you are not, I am grateful.
I am not trying to single out you or anyone to feel bad.
I hate it when people do that to me, and I don't do it to others.
> I have already twice expressed my
> dignified sympathy, and I frankly don't know what else
> anybody can do when faced with this kind of extended
> regurgitation of grief.
I don't expect more of you. These remarks on my part are simply
to make sure my point is clear on the record since you have in spite
of your staements of sympathy also herein included additional remarks
about me which I felt required a reply. This will be my last detailed
statement on the social nature of this since I've pretty much established
my position on my original remarks, and since I don't plan to play
Zeno's Paradox with you, dissecting this conversation into infinity.
> If, on the other hand, you are indeed locating me in
> that noisome catalog of yours, at least there is some
> comedy value to it. Nothing in my two articles can or
> should be taken as a brief for Scheme in general or
> hygienic macro systems in particular.
Nor should anything in my "articles" be taken to say there is anything
wrong with Scheme having those. For reasons probably personal to me,
and perhaps not general to others, I personally find the Scheme macro
system painful and ugly, and I never myself use it. But I know others
that do use it, and I certainly use macros others have written, and
I'm sure that as a matter of technical workmanship and design it's a
fine thing. (My personal quibbles with it are philosophical, not practical.)
I assume someone must like it because it's there. I'd have gone for
syntactic closures, myself, in the context of Scheme. And I'm happy
to do my macro programming in CL where the issue just doesn't arise...
> Indeed, I quite
> agree with you that developments in Scheme have made it
> seem to some that hygienic macro systems are necessary
> when they aren't really. I am just saying that having
> one or two or many namespaces has no valid bearing on
> which way one chooses to jump on the hygiene issue.
I think this isn't so, but recognize the right of others to disagree
on this as a technical matter. I base my belief in part on the
technical matter of Lisp1 and in part on the nearly-consequential
sociology that emerges from the technical choice. As a matter of
observed sociology, I think it does matter. Science does not
recognize "my hunches" or "my gut feelings based on personal societal
observation" as a proper scientific method of analyzing data per se,
so I forgive you for disagreeing. But on the other hand, Science does
not say that everything it rejects on the basis of lack of evidence is
false, so please forgive me for believing that the namespace issue
matters even though you don't think so.
I have written a long post on this a long time ago, and you may be
able to find it on deja news. I promised Erik a long time ago that I
would write this up as a real article that I could reference but never
have done so. I'll keep trying to find the time. But it's not that
I've never spoken in detail on it. I just picked a bad forum.
(please no residual converation about my having called comp.lang.lisp
a "bad forum" :-)
> That, it would appear, is our only disagreement, or
> maybe even not -- I am fast losing track of what you're
> trying to say because you are getting way too
> discursive.
Thank goodness it is only me.
Dorai Sitaram
>
> excuse me, but why should I feel any better about Scheme, now? you
> attack one of the most knowledgeable persons in _both_ communities for no
> reason at all. is this _another_ instance of "political correctness"?
>
> tell you what: I want to write nice, working programs that don't take
> forever and to use as much of the legacy of mankind as possible in the
> process. that's why I can't stand Scheme, which makes me feel like I
> have been given exquisitely shaped flint stones and a beautifully
> prepared coat made from a bear's hide, and then I have to re-invent
> everything from there, which will neither be exquisite nor beauitiful
> because I don't have 40,000 years to reinvent everything from where
> Scheme left us in anything but rough ways. since Scheme people tend to
> be extraordinarily proud of their hand-made bear coats and swing flint
> stones like no one has ever seen and then challenge everyone they meet to
> compete with them on such terms, especially Common Lisp people, I also
> find little reason to frequent Scheme communities. when you arrive with
> your own neanderthal attitude, Dorai, I tend to think that Scheme people
> should be left alone, possibly relocated to a reservation, but let's make
> sure we don't leave any metal ores nearby. there's no telling what would
> happen if the Scheme community discovered bronze, or god forbid, iron.
> but at least you're _incredibly_ hygienic and elegant, and I, too, admire
> your fine flint stones, as long as I don't have to use them for anything.
I have no problem with this kind of characterization of
Scheme. Scheme is indeed unusable for many, nay, most
purposes. As I said earlier, my response to Kent is
not a defense of Scheme or the Scheme community at all.
Heck, it is not even a defense of hygienic macro
systems.
Something very strange is going on in this thread.
--d
Tim Bradshaw
> glad you asked that: then I would use a function, not a macro.
> macros just placeholders, they should not infect others.
> (100% unintentional)
> using macros just not to evaluate one of its arguments is lame.
> lambdas are better.
Presumably you'd weaken this in the case where the name came from the
user, or you rule out most of the WITH-x macros (and, in a slightly
alternative universe, you rule out LET too...).
--tim
Howard R. Stearns
Eclipse calls this WITH-UNIQUE-NAMES. (Note that
with-unqique-names/with-gensyms is a little different than William's
hygenic-let example.)
Anyway, if you find WITH-UNIQUE-NAMES useful (as I do every day) then
you will also find REBINDING useful, too. (REBINDING serves the same
purpose as what is called ONCE-ONLY in some implementations.) The doc
for both is at http://www.elwood.com/eclipse/rebinding.htm and
http://www.elwood.com/eclipse/unique.htm
Here's a definition for both. (I'm with Erik on the issue of having
macro-generated symbols use the names provided by the programmer. You
can disagree and use GENSYM if you like.)
A smile-and-a-handshake to anyone who can lucidly explain (no pun
intended) WHY the REBINDING code works, or conversely, convince me that
it doesn't.
(defmacro WITH-UNIQUE-NAMES (vars &body body)
`(let ,(loop for var in vars
collect `(,var ,(copy-symbol var)))
,@body))
(defmacro REBINDING (vars &body body) ;difficult code here!..
(loop for var in vars
for name = (copy-symbol var)
collect `(,name ,var) into renames
collect ``(,,var ,,name) into temps
finally (return `(let ,renames
(with-unique-names ,vars
`(let (,,@temps)
,,@body))))))
Johan Kullstam wrote:
>
> wtan...@dolphin.openprojects.net (William Tanksley) writes:
>
> > On Wed, 08 Sep 1999 20:10:23 GMT, Reini Urban wrote:
> > >Stupid subject line.
> >
> > Grin.
> >
> > >But reading the Tanksley-Joswig talk, Tanksley complaining about the
> > >semantic problem with macros, I thought why not writing a compiler which
> > >can automatically rename such captured vars in a new special form,
> > >defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown
> > >away then :)
> >
> > No! Anaphor is a powerful thing, and any change to avoid its bad effects
> > would also destroy its good ones (and thus obsolete all macros).
> >
> > Lisp doesn't need to be changed to avoid accidental symbol capture. All
> > you have to do is define and use a very simple macro, let's call it
> > "hygenic-let", which uses 'let' and 'gensym' to create new variables which
> > will shadow the old ones.
> >
> > An example of its usage would be:
> >
> > (defmacro duh (x y z)
> > (hygenic-let ((i 1) (j 2))
> > (do-things i x y z)
> > j))
> >
> > Make sense? This has just declared i and j to be hygenic -- secretly,
> > it's replaced every use of i and j with a new gensym.
> >
> > 'On Lisp' defines this macro, IIRC, but I don't remember what it
> > called it.
>
> graham called it WITH-GENSYMS
>
> (defmacro with-gensyms (syms &body body)
> `(let ,(mapcar #'(lambda (s)
> `(,s (gensym)))
> syms)
> ,@body))
>
> here's an example of its use
>
> (defmacro allf (val &rest args)
> (with-gensyms (gval)
> `(let ((,gval ,val))
> (setf ,@(mapcan #'(lambda (a) (list a gval))
> args)))))
>
> i find WITH-GENSYMS to be highly useful.
>
> > >No really, a decent compiler should be able to do the static analysis of
> > >possible variable captures in special macros and rename/gensym them.
> > >(Letting dynamic creation of such DEFSAFEMACRO's aside.)
>
> nod. INLINE is supposed to do this (no comments about any particular
> implementations). this also barring the effect of SETF not
> escaping the scope of the function problem.
>
> --
> J o h a n K u l l s t a m
> [kull...@ne.mediaone.net]
> Don't Fear the Penguin!
William Tanksley
>Raymond Toy wrote:
>>If your compiler is smart enough to know when NOT to gensym something,
>>then surely it would be smart enough not to waste resources and
>>performance when you DO gensym everything.
>>How would you tell such a compiler that you really do want variable
>>capture?
>glad you asked that: then I would use a function, not a macro.
>functions should have distinctive variables.
>macros just placeholders, they should not infect others.
>(100% unintentional)
I don't see how a function would be able to 'infect others'. As far as I
can see, only special forms and macros can do that.
Other than that, though, I would have designed the macro system as
hygenic, but with provision for anaphora. Perhaps this would make it
non-Lisp; if so, we can all be thankful that I am doing no such thing, nor
will I.
>using macros just not to evaluate one of its arguments is lame.
>lambdas are better.
You mean for lazy evaluation? That doesn't have anything to do with
symbol capture or anaphora.
Macros lack some of the characteristics of functions in Lisp. It might be
interesting to design a variant in which they had some of those
properties. I can already see how to design such a variant of Forth,
although it would require a better memory management system than Forth
currently has (it would also be very unForthlike).
I'm not going to even think about it, though -- reading On Lisp has given
me a lot better feel for Lisp, but I'm not that much in touch yet with
what makes Lisp Lisplike :).
>Reini Urban
--
-William "Billy" Tanksley
William Tanksley
>ds...@bunny.gte.com (Dorai Sitaram) writes:
>> I wasn't asking you to be polite or not to flame. I
>> was asking you not to contribute to misunderstandings,
>If you go back and re-read the conversation, I think you will see I
>attacked no one.
I don't see him as claiming that -- a flame usually doesn't contribute to
misunderstandings, but rather causes altogether too much understanding. :(
>It's possible that your gripe is that in fact I did
>attack no one since then that person would be morally empowered to
>defend him or herself. However, I was responding only in kind to a
>prior message which spoke about a general problem without specifics as
>well, and I was doing my best to speak at the level of abstraction
>already introduced and in the context already introduced.
I found your post interesting, since I had taken a contrary position; at
the same time, I don't believe that you established your point, especially
since rather than proving that the problem doesn't affect Lisp or can't be
considered as a problem, you merely stated that as truth and then
attempted to impugn Scheme as having other problems.
>Looking over my original message, the only statement I can think of
>which I made which might be controversial was this one, which you
>chose to respond to by attacking me pesonally rather than by merely
>addressing the technical statement I made:
>kmp> They are only really unsafe in Scheme, which has no package
>kmp> system and only one namespace.
>In defense of this remark, my use of the word "unsafe" was merely
>following in the same literature that the Scheme community has used
>this term in macros. There is a technical sense in which "unsafe"
>means "capable of accidental capture" and that's a true and defensible
>claim.
This would be entirely true if Scheme's macro system were unhygenic -- but
it isn't. Its hygene is an essential part of its construction, more so
than Lisp's package system is part of its macro system (if I may make the
ridiculous comparison).
>If you want to add additional remarks saying that you have other
>experiences, you're welcome to, but don't say I'm contributing to
>confusion merely by restating the problem in a way that is faithful
>to the original statement of the problem by the community that originally
>established the issue. Further, it is true that Scheme has no package
>system--it has a module system. And it is, like it or not, a common
>oversight by people from the Scheme community who are unused to the package
>system to say you can't write a macro that will avoid capture problems
>when in fact, it's trivial to write a great many macros that will avoid
>this if you just have either GENSYM or else MAKE-PACKAGE and INTERN.
>So I don't see how I was contributing to a confusion by saying this.
It's ridiculous, obviously, to claim that it's impossible to write a safe
macro in Lisp. GENSYM makes it all possible. The "problem" is that a
safe macro is a very complicated macro. My ideal would have safety be the
default, and anaphora require a brief workaround (certainly nothing
complicated).
However, this is somewhat of an aesthetic judgement, and after spending
some time with Scheme, I have to agree that aesthetics are not the best
judge of language power.
>The remainder of my message aws:
>kmp> Macros are not generally unsafe in Lisp.
>This statement is true and supported by lots of actual practice.
>It does not, in my opinion, contribute to any misperception or confusion.
It's true in the sense that macros can _always_ specifically be made safe
in Lisp.
>kmp> Lisp has used its simpler macro system with great success and
>kmp> very little problem for many years and unintentional variable
>kmp> capture doesn't require anything as sophisticated as a special
>kmp> defsafemacro.
>This statement also seems true to me even in hindsight.
I have a problem with it. Please help me correct my problem.
You say that Lisp's macro system is "simpler". Presumably you mean
simpler than Scheme's, or perhaps simpler than defsafemacro. Yet it seems
to me that in order to make safe macros in Lisp, you have to be immensely
more careful and knowledgable about some huge complexities than you have
to be in Scheme.
>kmp> This is a common misperception about Lisp which people carry
>kmp> in from Scheem.
>This statement seems true to me.
It certainly seems accurate to me -- I came in from Scheme, and I have
that perception. I'd still like to know why it's wrong, although I
certainly don't insist on it. I'll be spending plenty of time with Lisp
-- it's a better language than Scheme, no doubt.
>It is a common misperception.
I'd _love_ to hear why it's false. I hear you describing how Scheme would
be dangerous without hygenic macros, and I believe it. I read "On Lisp"'s
discussion of how Lisp is dangerous without careful attention to every
symbol, and I believe that. Hygenic macros cause me no effort and don't
add to my code's visual complexity; watching and guarding every symbol
does.
Note that I'm not contradicting you, merely describing my own feelings
about my experiences.
>kmp> People need to understand that problems always exist in a
>kmp> context.
>It's hard to see how this contributes to a misperception or confusion.
>kmp> Moving to a new context requires reevaluating the issues
>kmp> in the new circumstances, not just assuming they carry over.
>Ditto.
It's clear that I need some help in doing that reevaluation. If I don't
get it, I'll still stick with Lisp, so no pressure.
>That concludes the entirety of my message which you chose to single out
>an request I ""not [...] contribute to misunderstandings" with. I stand
>by my claim that I did not. And further I stand by my claim that if there
>was or ever is a misunderstanding in what I say, the right thing is simply
>to address it at the appropriate technical level. I think I have an
>established record of acknolwedging errors and confusions in what I've said,
>or even of acknowledging legitimate points of view that I happen not to
>agree with. I see no reason to get personal.
Again, I think his offence was mainly to your attacks against Scheme,
which were made as though Scheme didn't have a hygenic macro system.
You may not have contributed to misunderstandings (although I'd say that
calling Scheme's macro system hazardous is a misunderstanding). You
certainly, however, did nothing to remove any of those misunderstandings
-- you merely called them out as such.
I can see how that would be insulting to many people who held those
misunderstandings as though they were facts -- a discussion of why their
opinion was a misunderstanding would be interesting, but simply calling it
a misunderstanding isn't.
Is there a web page on this? Or does "On Lisp" have something about it?
--
-William "Billy" Tanksley
Gareth McCaughan
> The thing that I value the most about CL and
> its community is its ability to embrace multiple concepts and multiple
> ways to think about things;
Well, since R5RS Scheme has had multiple values too, so perhaps
things are getting better in that camp. :-)
--
Gareth McCaughan Gareth.M...@pobox.com
sig under construction
Ben Goetter
> kmp> They are only really unsafe in Scheme, which has no package
> kmp> system and only one namespace.
>
> In defense of this remark, my use of the word "unsafe" was merely
> following in the same literature that the Scheme community has used
> this term in macros. There is a technical sense in which "unsafe"
> means "capable of accidental capture" and that's a true and defensible
> claim.
> The remainder of my message aws:
>
> kmp> Macros are not generally unsafe in Lisp.
>
> This statement is true and supported by lots of actual practice.
> It does not, in my opinion, contribute to any misperception or confusion.
I beg your pardon, but using what appears to be two definitions of
"unsafe" contributes to confusion.
Of course a Lisp programmer always uses gensym where appropriate to write
a safe macro; thus also with Scheme, as any environment with defmacro
will also have gensym. (If the Scheme lacks defmacro, how can it be
unsafe? Unuseful, maybe, but unsafe?)
So they're either both "unsafe" (with quotes - the "capable of accidental
capture" defn), or they're both "safe enough."
[I know that you're going to to respond "I know, I know - look, I was
hacking on (NOT NIL) when you didn't know a LABELS from a LAMBDA." This
is about contributing to confusion, not educating Kent. I am here to
learn from Kent, not educate him. Obviously. So enough confusion
already.]
Thomas A. Russ
>
> * Johan Kullstam
> | graham called it WITH-GENSYMS
>
> I have found COPY-SYMBOL to be superior to GENSYM in that the symbols
> produced have understandable names, which helps a lot when looking at the
> expansion and at the produced code.
I'm curious why you find COPY-SYMBOL better than GENSYM with an optional
argument. It would seem that if you ever have nested macros that use
the same names, it would not be possible to distinguish the names
produced by COPY-SYMBOL, since they would print the same. At least with
the GENSYMs, you can expect that two instances of #:COUNTER-4569
actually refer to the same variable.
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Gareth McCaughan
> (defmacro WITH-UNIQUE-NAMES (vars &body body)
> `(let ,(loop for var in vars
> collect `(,var ,(copy-symbol var)))
> ,@body))
Aren't you missing a "'" before the second "," on the third line?
Dobes Vandermeer
>
> Of course I know "On Lisp" and the scheme macros which suffer from the
> Lisp1 decision.
>
> But reading the Tanksley-Joswig talk, Tanksley complaining about the
> semantic problem with macros, I thought why not writing a compiler which
> can automatically rename such captured vars in a new special form,
> defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown
> away then :)
I feel like I am missing something important here, so I have to ask:
What is the semantic problem with macros that you are referring to?
Thanks
Dobes
Erik Naggum
| Of course a Lisp programmer always uses gensym where appropriate to write
| a safe macro; thus also with Scheme, as any environment with defmacro
| will also have gensym. (If the Scheme lacks defmacro, how can it be
| unsafe? Unuseful, maybe, but unsafe?)
as I understand this, Scheme cannot generate symbols on the fly in code
in the first place, since the language is not defined in terms of sexprs,
but in terms of a grammar with a lexical analysis phase, and that it
wouldn't help with _possible_ conflicts, since there is no concept of
"uninterned symbol" (due to lack of a package concept), they do such
things with LAMBDA and its "renaming", anyway, which is lexical, and if
Scheme had had DEFMACRO, it would have been tremendously dangerous, since
it couldn't possibly be safe in Scheme, lacking all the machinery.
at key here is understanding the Scheme community's attitude towards
DEFMACRO in Common Lisp. simply put: they don't understand it, because
they lack the concepts to deal with what which makes macros safe in CL.
lack of concepts usually leads to an incredible amount of confusion, but
the Scheme community has voluntarily rejected a number of concepts, which
for a number of reasons they can't go back on, and having to do so would
in turn cause massive upheaval. thus the emotional intensity. Scheme
has reached its evolutionary apex, and anything you can do from here on
will be perceived to reduce the language. this is OK by me, actually,
since I think Scheme is hurting the Lisp community every time a Scheming
bastard tries to pass Scheme off as "Lisp" sans qualifications.
Reini Urban
>> dynamic lisps like elisp or autolisp.
William wrote:
>Yup. But does that make CL wrong?
not wrong, only worse than it could have been.
>Maybe elisp or autolisp should be lexically scoped. Join the 90's &c :)
that's a different story. <sigh>
it's hard to maintain backwards compatibility with millions's of
"dynamically scoped" (i know, this is a wrong term) legacy code.
with new keywords no problem. but scope is not the problem. well, in my
case it makes things worse because ALL possible candidates may "infect"
the var (placeholder) in the macro, not just the lexically visible.
>> Looks like that I have to patch a CCL copy just for fun, to see if it
>> makes sense to me.
>
>What is a CCL?
Corman Common Lisp
>> (my local newsfeed is a mess nowadays. 10-20 hours for this...
>Bad news :(
I complained and the news admin rebooted the machine. It seems to be
much better now. Sometimes and in certain fields complaining DOES make
sense :)
--
Reini _NSAKEY ist mir schon gar nicht mehr wurscht.
Reini Urban
>> But reading the Tanksley-Joswig talk, Tanksley complaining about the
>> semantic problem with macros, I thought why not writing a compiler which
>> can automatically rename such captured vars in a new special form,
>> defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown
>> away then :)
Dobes Vandermeer wrote:
>I feel like I am missing something important here, so I have to ask:
>What is the semantic problem with macros that you are referring to?
that macros are quite unreadable and maintainable.
take a look at "On Lisp" or the typical macros.
and compare this to scheme macros or with-gensym approaches. the rest of
my complain was only about efficiency. how to improve with-gensym, not
to gensym every var, only those which are needed.
secondly, I do care about newbie's (the AutoLISP crowd) who should be
able to understand a macro system (easy) and write correct code then
(hard).
semantics are very important for newbies.
another story with semantics is nested backquoting.
but better have the ` than doing it explicitly.
I know this. I don't even have ` and , not macros in AutoLISP, so I have
to write the expansion explicitly (once) and have to read this mess
(every day).
` comes best to what one could expect for a decent language.
Reini Urban
>* Reini Urban wrote:
>
>> What I don't like with user-defined gensyms in macros is
>> unreadability, hard to write and somewhat knowing in advance
>> which vars can get captured. (really every?)
>
>something that binds variables, you need to make sure those variables
>have unique names, unless you intend them to be visible in the
>expansion (which is surprisingly often the case).
>
>> Of course you can gensym all your vars in the macro, but this might
>> be a waste of resources (and performance).
>
>I can't imagine a realistic case where it has any significant impact
>on either, unless you have a really slow compiler.
With my compiler (Visual Lisp) I see the difference, because it has to
deal with a dynamic lisp (all vars are global!), and cannot "localize"
(stack-allocate) somewhere globally used vars. (not only those in
lexical context). The performance lost is measurable and annoying in my
libraries.
Gensym'ing all those candidates is slow because gensym is the same hack
as in elisp, interning concatenated strings explicitly, in the global
enviroment.
The compiler is not slow but the resulting code. With proper compiler
analysis it can be improved dramatically in my case.
If it would matter in a decent common lisp implementation I may doubt as
well. Gensym should be fast enough there. esp. because it is only
created in lexical context, so stack-allocated.
sorry for bothering you guys with the better tools.
Reini Urban
>OK, write a function which allows you write code more or less like
>this:
>
>(asetf (second list) (+ it 7))
please not THIS. "Where comes this 'it' from?" a newbie would ask.
no magic names please. perl already has too much. this makes lisp way
too perl'ish.
and it fails in nested A... constructs as someone from the westcoast
(barry, peter ?) complained last month. ACOND, AIF, AWHILE and such.
it is not the right thing for language design, but it is the right thing
for user code. well, it helps a lot.
Reini Urban
>* Reini Urban
>| using macros just not to evaluate one of its arguments is lame.
>| lambdas are better.
>
> vs Lispn thing really _is_ about doing things one way or one of n ways.
this has nothing to do with multiple or singular namespaces.
> what I really _don't_ understand is why Scheme freaks need to _prove_
> Kent's points. it would seem much more rational to work very hard to
> _disprove_ all his claims.
i'm no scheme freak at all. i prefer lisp by far.
(besides demanding tail-call-elimination, but practice is different)
i'm with kent. his claims are rational and politically correct.
my purpose was not to attack common lisp. only to ask how to improve
macro semantics and performance (which are an unsolvable problem and a
non-existing problem, i know).
Reini Urban
>(and, in a slightly alternative universe, you rule out LET too...).
You know, I've always had a bad feeling about LET too :)
I cannot create bindings just for debugging purposes by marking the
binding form with the mouse and evaluate it. With the let syntax this is
impossible. With &aux and following setq's it is possible.
and here you caught me again: (sorry, if someone caught me wrong before.
this is nothing against lisp, only another newbie question)
let* and efficiency
i really don't know if the expansion of LET* (into to nested lambdas) is
a good thing or if it should be a special form instead, which can bind
in sequence internally without having to call nested lambdas. lambda
might have some overhead which is not needed in the context of LET*. (?)
but I might be wrong. binding in sequence might require a full LAMBDA to
be correct.
(I don't have SICP or WINSTON/HORN here in the office to prove it by
myself, so I have to sleep over it)
Iver Odin Kvello
EN> lexical, and if Scheme had had DEFMACRO, it would have been
EN> tremendously dangerous, since it couldn't possibly be safe in
EN> Scheme, lacking all the machinery.
Gambit Scheme has no hygienic macro system built-in; it does however
have a DEFMACRO-like system with gensym and all the necessary
machinery. This is essentially no more a problem[1] than it is in CL (and in
my opinion, this means not a problem at all.).
Also, in the R5RS under 6.3.3, Symbols: "Some implementations have
'uninterned symbols' ...".[2]
The 'problem of unintentional capture' still remains if you accept, as
some must have done, that the possibility of this is a problem in and
of itself, of course, and given that DEFINE-MACRO (which is the
DEFMACRO-in-scheme) fails to solve this problem, then it is unsafe in
the technical sense mentioned. It's pretty clear that this is the
unsafety (is that a word?) deemed problematic, and not just inside of
Scheme, I think, whether or not it was seen to be more problematic
there. Then again, there are other (technical, percieved) problems
solved by the Scheme systems, and having programs be other than
s-expressions is one of them[3] - useful for doing Dylan at least... I
probably need some emoticon here to avoid being roasted. "%/&.
Oops. Well, anyway.
The program-as-text thing of the RnRS is pretty strange though; I've
never seen any real argument of why it's supposed to be a good idea[4]. It
does of course complicate the whole concept of macros, but what really
puzzles me is eval, 6.5.5: "/Expression/ must be a valid Scheme
expression represented as data, ..." Hm.
Personally, I really like real, DEFMACRO-style macros, with programs
represented as sexps and with the full language available for
transforming them. It's much simpler to explain and understand and to
*implement* for one thing - hygienic macros have been around for a
long time, but people haven't really rushed to implement them in any
kind of lisp. DEFMACRO obviously isn't a safe-syntactic-abstraction-Right
-Thing all by itself, but it seems pretty Right-Thingish anyway, given
what it can do.
Footnotes:
[1] There are obviously more ways in CL than in Gambit for avoiding
name conflicts, but the ones present in Gambit are sufficient, given
care. I accept that CL would require less care, or tolerate more
carelessness.
[2] With 'uninterned' quoted, and no explaination of what interning a
symbol might mean. It guess it really helps to understand Lisp if one
wants to understand Scheme.
[3] The other ones I've found mentioned has been a more restricted
form of transformations (especially not allowing side-effects) and
making macros easier to write and/or read, meaning macro-by-example.
I've found these last two desiderata really, *really* frustrating when
trying to use the recently standardized system for anything a bit
complicated. Macro-by-a-really-big-lot-of-examples-with-some-bits-
missing-and-a-nifty-trick-involving-the-string-"snork".
[4] I've read H.Bakers paper about why it is a really bad idea, though
(Critique of DIN Kernel Lisp) and that seemed pretty much like the
last word on the case for me. So perhaps I just didn't get it.
--
(define (cthulhu_fhthagn) ; Iver Odin Kvello, iv...@hfstud.uio.no
(call/cthulhu (lambda (destroy) ; Lambda, the Ultimate Horror
(if (stars-are-right? (now)) (destroy 'everything) (cthulhu_fhtagn)))))
Kent M Pitman
> my purpose was not to attack common lisp. only to ask how to improve
> macro semantics and performance (which are an unsolvable problem and a
> non-existing problem, i know).
There is nothing wrong with macro semantics in CL. What is there is
sound, it just works by different principles than does the Scheme
mechanism. Principles that are appropriate and natural to the CL
context, where people are pervasively used to implementing separation
of modularity using difference in symbol names by packages.
The reason I object to the use of the phrase "improve macro semantics"
is that it implies an incremental refinement to the CL mechanism,
which would not "improve" the semantics. An incremental refinement
would add a layer atop what is there but would not change what there
is, and so would be no more nor less semantically strong than what was
there because it would not change its degree of semantic goodness.
It sounds to me like you mean either "change macro semantics" which would
improve some things while breaking everything else (and CL relies to a huge
extent on macros in very fine detail) or else what you are asking for is
a "syntactic", not "semantic", change.
In the former case, you are violating an explicitly stated principle of
the language design, which is stability and a focus on tried-and-true
and well-accepted techniques [and I shouldn't have to say this, but that
has to mean "tried WITHIN the context of CL" not "tried for some other
community"--saying that Scheme-style macros have been "tried" would be
disingenuous and in violation of accepted scientific method. No controlled
experiment has been tried rewriting substantial large-scale systems that
are heavily based on CL-style macros to see if they could as easily be
written using the Scheme macro system, for example, nor have communities
been given the option of both systems in a test environment to see which
they flock to].
In the latter case of my two from above, where the problem is merely
one of "syntactic sugar" on the existing macro system semantics, which
I'm assuming it more likely what you mean even though you're calling
it "improving macro semantics", the existing macro system, with its
present syntax and semantics, is capable of accomodating a syntax-only
change without any underlying change to what others are doing, just by
getting your own package and defining an appropriate macro that people
can use or not use as they like. Which if you do will also prove my
point that there was nothing semantically wrong with the existing
macro system.
I'm really not big on the whole "semantics" thing as a field of
study--to me, the definition of semantics is "means something
intelligible that I can write a compiler for"; I just can't read and
have little use for all that icky math at the back of the Scheme spec.
I'm happy that it's fun for someone, but it does nothing for me. So I
may be the wrong person to opine on this. But my seat-of-the-pants
understanding of semantics says that you're only "improving the
semantics" when you are "changing the semantics" + "the change is
positive". In this case, we can deftly duck the question of whether
the change is positive by observing that absent a request to change
how the language functions, and following up only on the addition of
an extra macro, you are still "compiling the code the same way" (my
definition of "having the same semantics") and consequently you are
not "improving the semantics" becuase you haven't changed it.
Perhaps that just means I'm a backwoods hick who's talking over his
head on a topic he shouldn't be opining about though... always a
possibility.
Kent M Pitman
> Tim Bradshaw wrote:
> >(and, in a slightly alternative universe, you rule out LET too...).
>
> You know, I've always had a bad feeling about LET too :)
>
> I cannot create bindings just for debugging purposes by marking the
> binding form with the mouse and evaluate it. With the let syntax this is
> impossible. With &aux and following setq's it is possible.
Uh, in the olden days, when life was better, we used to not depend so heavily
on "marking" as our only programming tool. If you're using Emacs, which is
extensible and customizable, or any of many vendor-specific clones that
are equivalent [just to drive home the point that it has nothing to do with
free software], you can just write something which does the action you want
on LET. The Lisp Machine has a number of little commands that manipulate
forms and do interesting things with them before executing. For example,
I'm pretty sure (because I think I wrote the code) that the LispM's
macroexpand command (c-sh-M) will not only macroexpand the following form
but will do it in a context where all of the textually visible containing
macrolets are active because it used to bug me that I couldn't debug my
local macros. If you just focus on complaining about local macros as
"thwarting easy debugging", you'd miss out on the fact that the language
is designed in a way to support flexible ways to help you. I just had the
editor do a series of up-s-expression (c-m-u) commands, looking for macrolet
and pasted together an appropriate expression that did something like
(eval `(macrolet ,containing-macros
(macrolet ((my-macroexpand (form &environment env)
`',(macroexpand-1 form env)))
(my-macroexpand ,macro-to-expand))))
or some such thing. can't remember exactly and am doing it off top of my
head. The point is you can do a similar emacs-like command which does
evaluate-let-body as a special command and which reconstructs the relevant
bindings + setq. For some reason, there has been a decline in this kind of
thing in recent years, I suspect because everyone got so Paste-happy.
But I don't understand it really because Paste is so mouse-motion-intensive
and that aggravates carpal tunnel syndrome, which a lot of people have.
Good Emacs commands take about one or two characters to type on the home
row of keys and because of the often-despised Lisp syntax with careful
balancing of everything can exactly determine what region of text is to
be manipulated without having to actually designate a region with the mouse.
> let* and efficiency
> i really don't know if the expansion of LET* (into to nested lambdas) is
> a good thing or if it should be a special form instead,
I don't understand this remark. The language does not forbid it from
being compiled as a special form. The language is carefully designed
to say that the availability of the macro is just so that if you're
wanting to write code that assumes a minimum number of special forms,
you can. But implementations can always offer more special forms as
long as it also offers macro definitions for them for the sake of
programs that don't expect them. It's hard to imagine how this can be
bad. Did you read about the definition of special forms in the HyperSpec?
> lambda
> might have some overhead which is not needed in the context of LET*. (?)
> but I might be wrong. binding in sequence might require a full LAMBDA to
> be correct.
> (I don't have SICP or WINSTON/HORN here in the office to prove it by
> myself, so I have to sleep over it)
Um, SICP is hardly an authority on Lisp. In Scheme, LET and LAMBDA have
a very simple relationship.
In Lisp, the used to be simply related but are less so now. The primary
difference is that declaration scoping is managed in an odd way that makes
the rewrite possible but a little trickier than it is in Scheme or was in
Maclisp before CL. Consider:
(let ((x y)) (declare (special x y)) (f))
The "meaning" of this is:
((lambda (x) (declare (special x)) (f))
(locally (declare (special y)) y))
In Scheme, there is no declaration facility, so they skirt issues like this.
Although declarations complicate Lisp, I think it's worth these small prices
to have declarations. Declarations allow you to tell compilers things that
type inferencing and other techniques either could not figure out
or would not typically figure out or that might take too long time to
figure out, and that often the user actually does know and can easily provide,
so it seems sensible to provide a mechanism for him to do that providing.
Erik Naggum
| Gambit Scheme ...
|
| Also, in the R5RS under 6.3.3, Symbols: "Some implementations have
| 'uninterned symbols' ...".[2]
we're talking about the _language_ Scheme, here. you just can't base a
_language_ feature on something that only exists in some implementations,
and you certainly can't dismiss it as if the existence of implementations
that go way beyond the standard is a feature of the language. quite the
contrary in my view. so I'm being anal and discuss the language as per
specification.
| The program-as-text thing of the RnRS is pretty strange though; I've
| never seen any real argument of why it's supposed to be a good idea[4].
well, it does make it much easier to construct tools for it in non-Lisp
languages, using lex/yacc, and more "usual" compiler techniques.
| DEFMACRO obviously isn't a safe-syntactic-abstraction-Right-Thing all by
| itself, but it seems pretty Right-Thingish anyway, given what it can do.
I agree with this, but I also think it is sometimes impossible to get it
all at once, and when this is the case, it's more important to settle on
_something_ and agree that the issue has been settled than to oscillate
between things you never settle on.
Marco Antoniotti
Gareth McCaughan <Gareth.M...@pobox.com> writes:
> Kent M Pitman wrote:
>
> > The thing that I value the most about CL and
> > its community is its ability to embrace multiple concepts and multiple
> > ways to think about things;
>
> Well, since R5RS Scheme has had multiple values too, so perhaps
> things are getting better in that camp. :-)
for the benefit of the Italians... dopo sette fette... :)
Cheers (apologies for the noise)
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti
ds...@bunny.gte.com (Dorai Sitaram) writes:
>
> I have no problem with this kind of characterization of
> Scheme. Scheme is indeed unusable for many, nay, most
> purposes. As I said earlier, my response to Kent is
> not a defense of Scheme or the Scheme community at all.
> Heck, it is not even a defense of hygienic macro
> systems.
>
> Something very strange is going on in this thread.
It is a simple Internet phenomena. I got caught in it myself. Your
post in reply to KMP, "sounded" horrifying to a lot of the readers of
CLL. That's all.
Now we can all go and have a bottle of Chianti.
Cheers
Rolf-Thomas Happe
> >(asetf (second list) (+ it 7))
>
> please not THIS. "Where comes this 'it' from?" a newbie would ask.
> no magic names please. perl already has too much. this makes lisp way
> too perl'ish.
BTW, such anaphoric macros can be recast in a more defensive, while
slightly more circumstantial, form that explicitly passes IT as an
argument to a one-place function:
(asetf (second list) (lambda (it) (+ it 7)))
or, according to taste,
(asetf (second list) => (lambda (snd) (+ snd 7)))
(The ornamental "=>" is stolen from Scheme's alternative COND form.)
rthappe
Marco Antoniotti
Iver Odin Kvello <iv...@hfstud.uio.no> writes:
> >>>>> "EN" == Erik Naggum <er...@naggum.no> writes:
>
> EN> lexical, and if Scheme had had DEFMACRO, it would have been
> EN> tremendously dangerous, since it couldn't possibly be safe in
> EN> Scheme, lacking all the machinery.
>
> Gambit Scheme has no hygienic macro system built-in; it does however
> have a DEFMACRO-like system with gensym and all the necessary
> machinery. This is essentially no more a problem[1] than it is in CL (and in
> my opinion, this means not a problem at all.).
Why use Gambit-Scheme if you cannot even port programs written for
a RxRS Scheme to it?
Craig Brozefsky
> Iver Odin Kvello <iv...@hfstud.uio.no> writes:
>
> > >>>>> "EN" == Erik Naggum <er...@naggum.no> writes:
> >
> > EN> lexical, and if Scheme had had DEFMACRO, it would have been
> > EN> tremendously dangerous, since it couldn't possibly be safe in
> > EN> Scheme, lacking all the machinery.
> >
> > Gambit Scheme has no hygienic macro system built-in; it does however
> > have a DEFMACRO-like system with gensym and all the necessary
> > machinery. This is essentially no more a problem[1] than it is in CL (and in
> > my opinion, this means not a problem at all.).
>
> Why use Gambit-Scheme if you cannot even port programs written for
> a RxRS Scheme to it?
Gambit claims to be R4RS supporting, so I don't see why one could not
run, no porting needed, R4RS programs on it. I run R4RS programs on
several scheme that support defmacro like extensions and many other
additions to RxRS. With packages like SLIB, one can even run defmacro
using programs on a large number of scheme implementations without
porting. So, I cannot make sense of your rhetorical question.
--
Craig Brozefsky <cr...@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"riot shields. voodoo economics. its just business. cattle
prods and the IMF." - Radiohead, OK Computer, Electioneering
Erik Naggum
| please not THIS. "Where comes this 'it' from?" a newbie would ask. no
| magic names please.
& <37da49ca.182323116@judy>
| I do care about newbie's (the AutoLISP crowd) who should be able to
| understand a macro system (easy) and write correct code then (hard).
I fail to see why it is necessary or even useful to bring this mythical
newbie into design discussions. it's like targeting political campaigns
_only_ towards first-time voters, or making TV shows only for people who
have never seen the show before. the most common effect of all this
focus on beginners is that more experienced users go elsewhere, mostly
because in newbie-friendly things you are unable to grow beyond a
certain, low point. call it the beginner's glass ceiling, if you want.
Kent M Pitman
[A good post, with some interesting references; my replies here are not
so much to you personally as to the thread generally based on a
few things you said. Please don't take any of this as me jumping
on you personally; I'd like to avoid another go-around like the last one.]
> Also, in the R5RS under 6.3.3, Symbols: "Some implementations have
> 'uninterned symbols' ...".[2]
The formal meaning of this (since I think the Schemer community is big
on formal meaning) is that "Scheme does not require uninterned symbols".
In case it's not obvious, the set of things Scheme does not require is
quite large (one might say "unbounded"); if one can count ever non-required
feature of Scheme to its credit, then let's count every non-required feature
of CL to its credit, too. Now we're comparing infinities. What fun.
The fact is that there exist some quality Scheme implementations. I
have always felt that the quality of Scheme implementations far
exceeded the quality of the Scheme language. In oh so many cases,
Scheme the Language is fully silent on things that are absolutely
necessary for any kind of portably useful outcome; that doesn't mean
there aren't useful programs you can write in portable Scheme, but it
means that that set is much, much smaller than the set of useful programs
you can write in non-portable Scheme. By the same metric, every feature
of the Lisp Machine can be counted as a feature of "common lisp", since
the Lisp Machine is compliant and just has "a few extra bells and whistles".
But what's the point of that?
> The 'problem of unintentional capture' still remains if you accept, as
> some must have done, that the possibility of this is a problem in and
> of itself
All languages are inherently a problem if people don't use the language
primitives in ways that avoid bugs. You should be careful with this. Even
without appealing to macros, Scheme is no more safe the Common Lisp against
"fencepost errors" either (even with tail recursion :-).
Scheme is not immune to "unintentional capture", it's only immune to a
specific kind of unintentional capture that occurs when you arrange things
just so. For example, in Scheme you can write:
(define (foo list) (list list list))
and if you didn't mean to capture the list function, you've unintentionally
captured it. People have in the literature defined this form to mean
"intentional capture"(TM) but that's idealizing the world to assume people
will make no programming mistakes. I think the whole English meaning of
"unintentional" has to include the possibility tht the programmer will space
out and don the wrong thing sometimes. If it does not, then unintentional
capture will never happen anyway since he will never use macros in the first
place in any situation that has the potential for unintentional capture.
Erik Naggum
| i really don't know if the expansion of LET* (into to nested lambdas) is
| in sequence internally without having to call nested lambdas.
I don't think we're in Scheme-land, anymore, Toto.
LET* _is_ a special operator in Common Lisp.
Iver Odin Kvello
MA> Why use Gambit-Scheme if you cannot even port programs written
MA> for a RxRS Scheme to it?
You can though, since there is some stuff available that implements
one of the hygienic systems, I forget which. And it has some pretty
good other features too - nice FFI and so on. My kind of macros.
Compiles to C, portable. Could be useful if you ever needed
continuations or something like that.
But I don't use it; I use CL. Not that I can port RxRS programs to
*that*, but hey, I'll live.
Iver Odin Kvello
EN> | Gambit Scheme ...
EN> | Also, in the R5RS under 6.3.3, Symbols: "Some
EN> | implementations have 'uninterned symbols' ...".[2]
EN> we're talking about the _language_ Scheme, here. you just
EN> can't base a _language_ feature on something that only exists
EN> in some implementations, and you certainly can't dismiss it as
EN> if the existence of implementations that go way beyond the
EN> standard is a feature of the language. quite the contrary in
EN> my view. so I'm being anal and discuss the language as per
EN> specification.
Well, I'll accept that at least for the sake of this argument. I'm
only arguing that this construct is possible; that is compatible with
the standard. This is of course a pretty remote what-if scenario, but
I still think one could fit a DEFINE-MACRO into scheme-as-described:
uninterned symbols are explicitly allowed; and the resulting expanded
list (data) created could 'represent' code in the same way as the
expression argument to eval.
It would be a bit harder to get this to seem neat though - I'm not
prepared to defend this aspect of Scheme at all, so feel free to rip
it up.
Gambit, by the way, doesn't cheat at this; it really treats programs
according to the standard. This is what Gambit does when given
non-program-syntax input:
> '(cons 'a . ('b))
(cons 'a 'b)
> (cons 'a . ('b))
*** ERROR IN (stdin)@13.1 -- Ill-formed procedure call
This is Allegro CL for comparison:
USER(1): (cons 'a . ('b))
(A . B)
Here is Gambit again, doing eval (Gambit allows omitting the
enviroment argument)
> (eval '(cons 'a . ('b)))
(a . b)
and again, define-macro:
> (define-macro (boing x y)
`(cons ',x . (',y)))
> (boing a b)
(a . b)
Erik Naggum
| *that*, but hey, I'll live.
would it really be useful to do that? SIOD (Scheme In One DEFUN) was a
Scheme-in-Common-Lisp. maybe there's still something around that can do
it for you.
Rainer Joswig
> >What is a CCL?
>
> Corman Common Lisp
Coral Common Lisp (CCL) is older. Hopefully Corman Common Lisp
doesn't have CCL on its list of features?!
Vilhelm Sjöberg
> we're talking about the _language_ Scheme, here. you just can't base a
> _language_ feature on something that only exists in some implementations,
> and you certainly can't dismiss it as if the existence of implementations
> that go way beyond the standard is a feature of the language. quite the
> contrary in my view. so I'm being anal and discuss the language as per
> specification.
One of the major goals with Common Lisp was portability between
different lisps, so features that only exist in some implementations
weighs lightly when one is assessing that language.
RxRS, however, has partially different goals. From the "Backgroud"
section:
>As Scheme became more widespread, local dialects began to diverge until students and researchers occasionally found it difficult to
>understand code written at other sites. Fifteen representatives of the major implementations of Scheme therefore met in October
>1984 to work toward a better and more widely accepted standard for Scheme.
Thus, the purpose of RxRS is not to define a langage rich enough that
all interesting programs can be written portably in it, but rather to
define a common subset, so that programs written in the different
dialects of Scheme that is defined by the different Scheme
implementations are intelligable to all members of the Scheme
community.
And so, a discussion of Scheme not only can, but must, take into
account the different features that exists in the various dialects.
Most comparisons between the "pure", "standard", RxRS version and
other programming languages will be to Scheme's disadvantage, since
almost no real programs can be written in that bare-bones intersection
between living languages (and almost none are).
-Vilhelm
Kent M Pitman
> * Iver Odin Kvello <iv...@hfstud.uio.no>
> | But I don't use it; I use CL. Not that I can port RxRS programs to
> | *that*, but hey, I'll live.
>
> would it really be useful to do that? SIOD (Scheme In One DEFUN) was a
> Scheme-in-Common-Lisp. maybe there's still something around that can do
> it for you.
Jonathan Rees's pseudoscheme runs fine in CL. We use intermixed Scheme
and CL for our projects.
Kent M Pitman
It's also "cambridge common lisp" (an old name for Hqn's lisp, I think;
lots of Harlequin system code uses #+ccl/#-ccl. sigh.)
Alan McLean
> * Iver Odin Kvello <iv...@hfstud.uio.no>
> | But I don't use it; I use CL. Not that I can port RxRS programs to
> | *that*, but hey, I'll live.
>
> would it really be useful to do that? SIOD (Scheme In One DEFUN) was a
> Scheme-in-Common-Lisp. maybe there's still something around that can do
> it for you.
scm2cl works fairly well
http://www.cs.rice.edu/~dorai/scm2cl/scm2cl.html
-amcl
Erik Naggum
| It's also "cambridge common lisp" (an old name for Hqn's lisp, I think;
| lots of Harlequin system code uses #+ccl/#-ccl. sigh.)
OK, I know what I want for the "revision" of ANSI Common Lisp: the
specification of a registry of feature symbols, to be handled by a
registration authority. this could also be an additional standard.
the registry would have to pre-register all known feature symbols and
accept collisions but also list how to disambiguate, but no new features
should collide.
Kent M Pitman
> Thus, the purpose of RxRS is not to define a langage rich enough that
> all interesting programs can be written portably in it, but rather to
> define a common subset, so that programs written in the different
> dialects of Scheme that is defined by the different Scheme
> implementations are intelligable to all members of the Scheme
> community.
> And so, a discussion of Scheme not only can, but must, take into
> account the different features that exists in the various dialects.
No. It needn't must. It could and I think should just assume that
the Scheme people had no interest in those features and any argument
that hinges on things in implementations but not the spec should be
lost by default.
> Most comparisons between the "pure", "standard", RxRS version and
> other programming languages will be to Scheme's disadvantage,
As well it should be, since the Scheme community voluntarily elected this.
> since
> almost no real programs can be written in that bare-bones intersection
> between living languages (and almost none are).
That's the bed that the Scheme designers made and now they must lie in
it. This is not some after-the-fact trap they didn't anticipate and
are being unfairly tossed into. This is a set of issues they knew would
come up and said they were comfortable not addressing.
I was at those design meetings. I suggested the language should be
more detailed in order to be more portable but that didn't enthuse
anyone. I would characterize the issue as overzealous pride in the
shortness of the document and a stubborn unwillingness to risk
increasing the size of the document in order to make it more clear.
My specific recollection is of how proud some of them were that they
had had to pad the document with other text not related to the spec in
order to make it thick enough to bind. I found that ridiculous and
more than a little objectionable since I disagreed with some of the
extra filler text they jammed into some of the documents, which
appeared by its placement in a document with my name on it to have my
endorsement. No vote was taken to do that--someone just made that
decision without actually asking the group. I just double-checked and
there's a note on page 45 of R3RS which mentions this issue of the
pagecount.
So it's possible that some individual designers objected, as I did,
and I don't mean to speak for them as individuals, but it seems to me
that as a body of the whole, the Scheme designers elected the
"shortness of the document" as a primary design criterion, and IMO
they ought to be judged on the basis of this as a primary criterion,
not given a pass on it. They had other options and voluntarily and
knowingly elected not to pursue them.
At one of the later meetings, I think, after CL had been deployed for
a while, I recall specifically cited the bad experiences we'd had with
porting CL in the early days and suggested that Scheme should learn
form this and nail things down. People were more concerned with Scheme
as a vehicle for targeting textbooks, at which they succeeded well.
If you think Scheme is about "concepts", then maybe it's succeeded; if
you think it's about sharing programs across implementations, I think
it's not done as well. I think it's a shame that those concepts don't
translate themselves into portable practice when they easily could
have.
In general, the Scheme design committee bogged down on the simplest of
issues because it had a terribly conservative voting process that
required all designers to agree. For years we were deadlocked over
whether to accept (define (foo x) x) as a synonym for (define foo
(lambda (x) x)), because some weren't sure that the former was
conservative enough. And, of course, there was a split for years
about NIL vs (). So you can imagine the difficulty of getting other
changes in...
If the Scheme community wants as a body of the whole to care about
PRACTICAL effects in languages, like porting issues, they have to
write a document that addresses that. IMO, to date, they have not.
Individual Scheme dialects do care about practicalities, and as I've
said, I have a great deal of respect for the work some vendors have
put into their implementations. But the language/spec is a different
matter from implementations.
Or so I think. And we all know that people don't always agree with
me. I've been at the Scheme meetings and listed as an author since R2RS,
but it's fair to say my opinions on most topics are not always regarded
as the "mainstream" point of view. I'm sure there's another point of
view to be had on all of this--but I'm afraid mine is the only one I have
easy access to offer... Just don't think I speak for the committee;
I speak only for myself and whatever peculiar bias I bring to the table
based on my experiences over here in CL-land.
Marco Antoniotti
Kent M Pitman <pit...@world.std.com> writes:
> So it's possible that some individual designers objected, as I did,
> and I don't mean to speak for them as individuals, but it seems to me
> that as a body of the whole, the Scheme designers elected the
> "shortness of the document" as a primary design criterion, and IMO
> they ought to be judged on the basis of this as a primary criterion,
> not given a pass on it. They had other options and voluntarily and
> knowingly elected not to pursue them.
Hey! You stole my idea for a posting. :)
Rainer Joswig
> jos...@lavielle.com (Rainer Joswig) writes:
>
> > In article <37da4743.181676927@judy>, rur...@sbox.tu-graz.ac.at wrote:
> >
> > > >What is a CCL?
> > >
> > > Corman Common Lisp
> >
> > Coral Common Lisp (CCL) is older. Hopefully Corman Common Lisp
> > doesn't have CCL on its list of features?!
>
> It's also "cambridge common lisp" (an old name for Hqn's lisp, I think;
> lots of Harlequin system code uses #+ccl/#-ccl. sigh.)
This explains remarks in code I've seen where they try to get rid of
the CCL feature, thanks.
Gareth McCaughan
> I just had the
> editor do a series of up-s-expression (c-m-u) commands,
This is such a valuable thing to be able to do that they even
named a Lisp implementation after it. :-)
--
Gareth McCaughan Gareth.M...@pobox.com
sig under construction
Dorai Sitaram
Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> wrote:
>ds...@bunny.gte.com (Dorai Sitaram) writes:
>>
>> I have no problem with this kind of characterization of
>> Scheme. Scheme is indeed unusable for many, nay, most
>> purposes. As I said earlier, my response to Kent is
>> not a defense of Scheme or the Scheme community at all.
>> Heck, it is not even a defense of hygienic macro
>> systems.
>>
>> Something very strange is going on in this thread.
>
>It is a simple Internet phenomena. I got caught in it myself. Your
>post in reply to KMP, "sounded" horrifying to a lot of the readers of
>CLL. That's all.
>
>Now we can all go and have a bottle of Chianti.
Thanks, Marco. And sorry for calling you Mario. It
was an unintent
(I guess I tend to visualize you as a Cipollini rather
than a Pantani. :-> )
--d
Marco Antoniotti
ds...@bunny.gte.com (Dorai Sitaram) writes:
> >Now we can all go and have a bottle of Chianti.
>
> Thanks, Marco. And sorry for calling you Mario. It
> was an unintentional variable capture.
>
> (I guess I tend to visualize you as a Cipollini rather
> than a Pantani. :-> )
As a matter of fact 20 year ago and 30 kgs ago I use to bike race :)
Then I decided that programming was less tiresome. :)
Howard R. Stearns
>
> Howard R. Stearns wrote:
>
> > (defmacro WITH-UNIQUE-NAMES (vars &body body)
> > `(let ,(loop for var in vars
> > collect `(,var ,(copy-symbol var)))
> > ,@body))
>
> Aren't you missing a "'" before the second "," on the third line?
Quite right. Thanks.
Serves me right for making a change on the fly for posting and not
testing it.
The code I had been using was ... (make-symbol ,(symbol-name var)) ...
and I figured that copy-symbol would be easier on the eyes for posting.
Now you've got me all worried that this change subtley effects
REBINDING, but I as far as I can tell, there shouldn't be any problem.
Per Bothner
> Personally, I really like real, DEFMACRO-style macros, with programs
> represented as sexps and with the full language available for
> transforming them. It's much simpler to explain and understand and to
> *implement* for one thing - hygienic macros have been around for a
> long time, but people haven't really rushed to implement them in any
> kind of lisp.
Actually, I suspect DEFMACRO style macros are much hairier to
implement that the simple pattern substitution of Scheme syntax-rule,
at least if:
(1) You are using a compiler. Now you suddenly you have multiple
compile-times, because you need to compile the macro transformers
before you compile the rest of the code. Hence the need for eval-when.
(2) You have macros which are defined at non-top-level. (I thought CL
had them, but now I can't find them. Probably for good reason.)
The nice thing about the pattern-based syntax-rules is that they are
just patterns. Thus their semantics are relatively clear. Defmacro
gets you into the complication of compile-time environment vs run-time
environment, and having them merge.
Many Scheme systems (including my own Kawa) have defmacros-style macros,
some in addition to define-syntax hygienic macros. A few (notably Chez
Scheme) have the syntax-case feature, which provides defmacro-style
rewriting *with* hygiene, *and* local (lexically-scoped) macros.
(Unfortunately, I haven't seen any good *specification* of syntax-case
to covers the corner cases, for example what lexical variables can be
used in a local macro transformer.)
--
--Per Bothner
bot...@pacbell.net p...@bothner.com http://www.bothner.com/~per/
Barry Margolin
William Tanksley <wtan...@dolphin.openprojects.net> wrote:
>It's ridiculous, obviously, to claim that it's impossible to write a safe
>macro in Lisp. GENSYM makes it all possible. The "problem" is that a
>safe macro is a very complicated macro. My ideal would have safety be the
>default, and anaphora require a brief workaround (certainly nothing
>complicated).
I believe Kent's point is that in Common Lisp, you can write a macro that's
generally safe even without the complicated GENSYM logic. If the users of
the macro are generally in a different package, and the variables you
introduce aren't exported from your package or imherited from a package
that the user's package is likely to :USE as well (e.g. the COMMON-LISP
package) then a conflict is extremely unlikely.
If the macro is used within the defining package, it's easy to avoid
inadvertent capture with reasonable naming conventions.
Then again, the same could probably be said of lexical scoping. Dynamic
scoping was a problem in Maclisp because it didn't have packages, so you
had inadvertent shadowing.
>You say that Lisp's macro system is "simpler". Presumably you mean
>simpler than Scheme's, or perhaps simpler than defsafemacro. Yet it seems
>to me that in order to make safe macros in Lisp, you have to be immensely
>more careful and knowledgable about some huge complexities than you have
>to be in Scheme.
He may have been referring to the simplicity of the way the macro system
works, not the way it's used. The Common Lisp macro system is trivial to
describe: an ordinary function takes the input S-expression as a parameter
and returns a new S-expression as a value, and that new expression is
processed in place of the original. Anyone creating a Common Lisp
implementation can implement the macro processor in seconds. The Scheme
macro system is not so simple to describe.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, 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.
Barry Margolin
Rolf-Thomas Happe <rth...@bonnie.mathematik.uni-freiburg.de> wrote:
>Reini Urban writes:
>
>> >(asetf (second list) (+ it 7))
>>
>> too perl'ish.
Well, the whole point of that macro is to introduce a magic variable with a
well-known name.
>BTW, such anaphoric macros can be recast in a more defensive, while
>slightly more circumstantial, form that explicitly passes IT as an
>argument to a one-place function:
>
> (asetf (second list) (lambda (it) (+ it 7)))
True, but one of the reasons we often use macros is to avoid explicit
lambdas. For instance, see the oft-repeated thread (especially in
comp.lang.scheme) regarding implementing IF as a function that takes lambda
expressions rather than a macro that takes ordinary expressions.
I imagine the "Schemy" way to implement an anaphoric macro would be to make
the pronoun be a parameter, e.g.
(asetf it (second list) (+ it 7))
This solves the hygiene problem and also allows nesting them:
(asetf it (second list)
(+ it (asetf him (aref other-list x) (- him 3))))
Perhaps a better example of intentional variable capture in a macro would
come from CLOS. I may be mis-remembering (perhaps what I'm thinking of is
in the condition system), but I think a common way to implement
CALL-NEXT-METHOD is by having the DEFMETHOD expansion bind this in an FLET
form.
Kent M Pitman
> I believe Kent's point is that in Common Lisp, you can write a macro that's
> generally safe even without the complicated GENSYM logic. If the users of
> the macro are generally in a different package, and the variables you
> introduce aren't exported from your package or imherited from a package
> that the user's package is likely to :USE as well (e.g. the COMMON-LISP
> package) then a conflict is extremely unlikely.
Yes, exactly.
Btw, regarding namespaces, I'll just summarize briefly:
I believe that as a matter of practice most people either avoid FLET or
LABELS entirely because they think it's ugly, or those that use it as a
matter of good style pick names that do not shadow globally defined names.
(This practice is reinforced by Emacs-like systems doing context-free
show-arglist and edit-function kinds of things, so it's painful to use a
shadowed name and get the correct behavior.) A consequence is that
if these simple style rules are observed, an they really often are,
then the "function namespace" is effectively a constant and can be relied
upon not to have shadowing problems anyway. This isn't as hard to
prove as one might think, since it's all your own functions and you can
know with reliability whether you program safely this way; and if it's
not all your own functions, you should be using a separate package.
In CL, it's variable names that are typically, well, variable. It is
considered by most people who are savvy in macro writing to be
extraordinarily por style to ever mention a variable by name in a macro
expansion unless the macro itself created the variable as a gensym or
as a bound varible itself. So again capture issues largely go away.
That reduces the cases to making sure you do create new variables in the
proper way, and I agree REBINDING and WITH-UNIQUE-NAMES recently discussed
here manage that just fine. In Scheme, because the variable namespace
and function namespace are collided, you effectively find an inability to
know which names in your expansion are likely to be "constant" and which
are "changeable" in terms of referent, so it's harder to reliably write
macros. That is the short form essence of the reason why namespaces
matter in macros. They wouldn't seem a priori like they did, but my belief
is quite firmly that established usage patterns have gravitated toward
this interpretation in CL. I imagine I've said this too briefly and
someone will have questions. I'll try to answer when I have time, or maybe
some helpful soul like Barry or Erik or Vassil will puzzle out what I mean
here and make it sound more clear.
As I mentioned, there is something on record about this already and
Deja News might turn it up. It's a couple of years back at least, I think.
Dorai Sitaram
Per Bothner <p...@bothner.com> wrote:
>Actually, I suspect DEFMACRO style macros are much hairier to
>implement that the simple pattern substitution of Scheme syntax-rule,
>at least if:
>(1) You are using a compiler. Now you suddenly you have multiple
>compile-times, because you need to compile the macro transformers
>before you compile the rest of the code. Hence the need for eval-when.
>(2) You have macros which are defined at non-top-level. (I thought CL
>had them, but now I can't find them. Probably for good reason.)
>
>The nice thing about the pattern-based syntax-rules is that they are
>just patterns. Thus their semantics are relatively clear. Defmacro
>gets you into the complication of compile-time environment vs run-time
>environment, and having them merge.
For this semantic (and implementational) clarity, do
you need macro expansions to be "just patterns", or
could you relax your requirement to that they be purely
source-to-source transformations, in particular: they
shouldn't rely on the text being transformed (by using
procedures or other globals defined in that text)?
A likely way to ensure this constraint would be to
continue to use defmacro, but with the easily
implemented proviso that the macro expansion will be
done in just the report-environment and nothing extra
-- so that it never ever uses or modifies the user
environment.
*
To answer your parenthetical question about
non-top-level macros in CL: Perhaps you think of
macrolet, which everyone pronounces macro-lay.
--d
Erik Naggum
| I'm curious why you find COPY-SYMBOL better than GENSYM with an optional
| argument. It would seem that if you ever have nested macros that use the
| same names, it would not be possible to distinguish the names produced by
| COPY-SYMBOL, since they would print the same. At least with the GENSYMs,
| you can expect that two instances of #:COUNTER-4569 actually refer to the
| same variable.
I think this is one of those problems that should not have a solution
because the causes of the problem should be examined very carefully to
avoid the problem altogether. if you get into a situation where you need
this sort of "control" often enough for it to be a real problem, you're
probably doing something wrong.
if I need such total disambiguation, I set *PRINT-CIRCLE* to true. I
also usually have *PRINT-GENSYM* set to false, but I'll happily let you
know that I implemented both PRINT-CIRCLE and PRINT-GENSYM in GNU Emacs
after I had implemented uninterned symbols for macro usage a few months
earlier. (all changes were accepted into the official distribution.)
#:Erik
Barry Margolin
>* Thomas A. Russ
>| I'm curious why you find COPY-SYMBOL better than GENSYM with an optional
>| argument. It would seem that if you ever have nested macros that use the
>| same names, it would not be possible to distinguish the names produced by
>| COPY-SYMBOL, since they would print the same. At least with the GENSYMs,
>| you can expect that two instances of #:COUNTER-4569 actually refer to the
>| same variable.
>
> I think this is one of those problems that should not have a solution
> because the causes of the problem should be examined very carefully to
> avoid the problem altogether. if you get into a situation where you need
> this sort of "control" often enough for it to be a real problem, you're
> probably doing something wrong.
While recursive macros are uncommon, that's probably the best example for a
case where this would be useful.
> if I need such total disambiguation, I set *PRINT-CIRCLE* to true.
Yes, that would work, but it's not as readable. #1# doesn't have as much
mnemonic value as #:COUNTER-4569, and if your macros are complex enough to
need this disambiguation, I think you'd want to make them as understandable
as possible.
Bernhard Pfahringer
Barry Margolin <bar...@bbnplanet.com> wrote:
>
>Yes, that would work, but it's not as readable. #1# doesn't have as much
>mnemonic value as #:COUNTER-4569, and if your macros are complex enough to
>need this disambiguation, I think you'd want to make them as understandable
>as possible.
>
>--
Which is why you'd want to use something like the following in
the first place (instead of copy-symbol, anonymous gensym, what have you):
(defun named-gensym (symbol)
"New symbol showing its heritage: old SYMBOL-name + a trailing counter"
(make-symbol (concatenate 'string
(symbol-name symbol)
"-"
(princ-to-string
(prog1 *gensym-counter*
(unless (fixnump (incf *gensym-counter*))
(setq *gensym-counter* 0)))))))
cheers, Bernhard
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence bern...@ai.univie.ac.at
Rolf-Thomas Happe
> True, but one of the reasons we often use macros is to avoid explicit
> lambdas. For instance, see the oft-repeated thread (especially in
> comp.lang.scheme) regarding implementing IF as a function that takes lambda
> expressions rather than a macro that takes ordinary expressions.
Yes. A genuine one-letter LAMBDA would be a major progress.
>
> I imagine the "Schemy" way to implement an anaphoric macro would be to make
> the pronoun be a parameter, e.g.
>
> (asetf it (second list) (+ it 7))
[...]
Maybe. I wouldn't get enthusiastic about this syntax. The current
R5RS Scheme has got pseudo-anaphoric (<test> => <expression>) COND
clauses:
(cond ((assv 'b '((a 1) (b 2))) => cadr)
(else #f))
==> 2
> Perhaps a better example of intentional variable capture in a macro would
> come from CLOS. I may be mis-remembering (perhaps what I'm thinking of is
> in the condition system), but I think a common way to implement
> CALL-NEXT-METHOD is by having the DEFMETHOD expansion bind this in an FLET
> form.
I believe Paul Graham mentions/explains this example in On_Lisp (or
was it ANSI_Common_Lisp?).
rthappe
Barry Margolin
Bernhard Pfahringer <bern...@hummel.ai.univie.ac.at> wrote:
>Which is why you'd want to use something like the following in
>the first place (instead of copy-symbol, anonymous gensym, what have you):
>
>(defun named-gensym (symbol)
> "New symbol showing its heritage: old SYMBOL-name + a trailing counter"
Isn't this identical to (gensym (symbol-name symbol))?
Barry Margolin
Bernhard Pfahringer <bern...@hummel.ai.univie.ac.at> wrote:
>In article <4ttD3.1002$m84.26959@burlma1-snr2>,
>Barry Margolin <bar...@bbnplanet.com> wrote:
>>In article <7rllt9$23dk$1...@www.univie.ac.at>,
>>Bernhard Pfahringer <bern...@hummel.ai.univie.ac.at> wrote:
>>>Which is why you'd want to use something like the following in
>>>the first place (instead of copy-symbol, anonymous gensym, what have you):
>>>
>>>(defun named-gensym (symbol)
>>> "New symbol showing its heritage: old SYMBOL-name + a trailing counter"
>>
>>Isn't this identical to (gensym (symbol-name symbol))?
>>
>yielding a less ambiguous name string:
If you want the hyphen, why don't you just include it in the call to
GENSYM, i.e. (gensym "FOO-") rather than (gensym "FOO")?
Anyway, your function can still be written much more simply:
(defun named-gensym (symbol)
(gensym (concatenate 'string (symbol-name symbol) "-")))
Bernhard Pfahringer
Barry Margolin <bar...@bbnplanet.com> wrote:
>In article <7rllt9$23dk$1...@www.univie.ac.at>,
>Bernhard Pfahringer <bern...@hummel.ai.univie.ac.at> wrote:
>>Which is why you'd want to use something like the following in
>>the first place (instead of copy-symbol, anonymous gensym, what have you):
>>
>>(defun named-gensym (symbol)
>> "New symbol showing its heritage: old SYMBOL-name + a trailing counter"
>
>Isn't this identical to (gensym (symbol-name symbol))?
>
Not quite, because you get the hyphen separating distinct counters
yielding a less ambiguous name string:
USER(2): (gensym (symbol-name 'a))
#:A474
USER(3): (gensym (symbol-name *))
#:A474475
USER(4): (named-gensym 'a)
#:A-476
USER(5): (named-gensym *)
#:A-476-477
So you know the last one was derived from A-476, whereas #:A474475 might
derive from A, A4, A47, ...
Bernhard Pfahringer
Barry Margolin <bar...@bbnplanet.com> wrote:
>In article <7rm5nm$4dmo$1...@www.univie.ac.at>,
>Bernhard Pfahringer <bern...@hummel.ai.univie.ac.at> wrote:
>>In article <4ttD3.1002$m84.26959@burlma1-snr2>,
>>Barry Margolin <bar...@bbnplanet.com> wrote:
>>>In article <7rllt9$23dk$1...@www.univie.ac.at>,
>>>Bernhard Pfahringer <bern...@hummel.ai.univie.ac.at> wrote:
>>>>Which is why you'd want to use something like the following in
>>>>the first place (instead of copy-symbol, anonymous gensym, what have you):
>>>>
>>>>(defun named-gensym (symbol)
>>>> "New symbol showing its heritage: old SYMBOL-name + a trailing counter"
>>>
>>>Isn't this identical to (gensym (symbol-name symbol))?
>>>
>>Not quite, because you get the hyphen separating distinct counters
>>yielding a less ambiguous name string:
>
>GENSYM, i.e. (gensym "FOO-") rather than (gensym "FOO")?
>
>Anyway, your function can still be written much more simply:
>
>(defun named-gensym (symbol)
> (gensym (concatenate 'string (symbol-name symbol) "-")))
>
Absolutely, I knew there was a simpler way :-)
Pierre R. Mai
> Barry Margolin:
> > True, but one of the reasons we often use macros is to avoid explicit
> > lambdas. For instance, see the oft-repeated thread (especially in
> > comp.lang.scheme) regarding implementing IF as a function that takes lambda
> > expressions rather than a macro that takes ordinary expressions.
>
> Yes. A genuine one-letter LAMBDA would be a major progress.
Well, it is easily defined via reader macros. Here are two variants,
one that makes parameter-less thunks, and another that mimics the
original lambda-calculus syntax (i.e. only one argument, and one body
expression):
(defun |{-reader| (stream char)
(declare (ignore char))
(let ((body (read-delimited-list #\} stream t)))
`(lambda () ,@body)))
(set-macro-character #\{ #'|{-reader|)
(set-macro-character #\} (get-macro-character #\)))
(defun |µ-reader| (stream char)
(declare (ignore char))
(let* ((arg (read stream t nil t))
(body (read stream t nil t)))
`(lambda (,arg) ,body)))
(set-macro-character #\µ #'|µ-reader|)
(defun |[-reader| (stream char)
(declare (ignore char))
(let ((body (read-delimited-list #\] stream t)))
(assert (>= (length body) 2))
(if (symbolp (first body))
`(funcall (function ,(first body)) ,@(rest body))
`(funcall ,(first body) ,@(rest body)))))
(set-macro-character #\[ #'|[-reader|)
(set-macro-character #\] (get-macro-character #\)))
Examples:
(defun test-if (test t-thunk nil-thunk)
(cond
(test (funcall t-thunk))
(t (funcall nil-thunk))))
(test-if (= 4 5)
{(print "Yes")}
{(print "No") (print "No") nil})
>> "No"
>> "No"
=> NIL
µa µb [+ a b]
=> #<Interpreted Function (LAMBDA (A) (LAMBDA (B) (FUNCALL #'+ A B))) {48149F41}>
[[µa µb [+ a b] 4] 2]
=> 6
Ugly but fun, isn't it? Though I fail to see the major progress that
one-character lambdas would give...
Regs, Pierre.
PS: The reason why µ is used instead of lambda is for ease of entry on
german keyboards using the latin-1 charset... ;)
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Thomas A. Russ
> * Thomas A. Russ
> | I'm curious why you find COPY-SYMBOL better than GENSYM with an optional
> | argument. It would seem that if you ever have nested macros that use the
> | same names, it would not be possible to distinguish the names produced by
> | COPY-SYMBOL, since they would print the same. At least with the GENSYMs,
> | you can expect that two instances of #:COUNTER-4569 actually refer to the
> | same variable.
>
> I think this is one of those problems that should not have a solution
> because the causes of the problem should be examined very carefully to
> avoid the problem altogether. if you get into a situation where you need
> this sort of "control" often enough for it to be a real problem, you're
> probably doing something wrong.
For example:
(dolist (i list1)
(dolist (j list2)
(when (eq i j)
(incf corresponding-elements))))
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Rolf-Thomas Happe
> Rolf-Thomas Happe <rth...@bonnie.mathematik.uni-freiburg.de> writes:
> > Yes. A genuine one-letter LAMBDA would be a major progress.
>
> Well, it is easily defined via reader macros. Here are two variants,
Ah, but I was thinking of a lower-case greek lambda put in a decent
position of my keyboard that I may use instead of the somewhat clumsy
LAMBDA - without any extra effort on my part (such as reading up on
character sets).
rthappe
Dorai Sitaram
Rolf-Thomas Happe <rth...@bonnie.mathematik.uni-freiburg.de> wrote:
>
>Ah, but I was thinking of a lower-case greek lambda put in a decent
>position of my keyboard that I may use instead of the somewhat clumsy
>LAMBDA - without any extra effort on my part (such as reading up on
>character sets).
An older Lisp book by Drew McDermott used the
single-character symbol \ as a macro alias for lambda.
He used this to save space while describing a
lambda-rich language written on top of his Lisp, and
that lambda-rich language was called... Schum. (Ha.)
CL and many Schemes use \ to escape the succeeding
character, so the symbol \ would be unusably verbose
(|\\|). Nevertheless, you can define the symbol made
up of one space -- written as \ followed by one space
-- to be your lambda. Unfortunately, this trick isn't
foolproof for the Schemes, since the character
following the lambda isn't guaranteed to be a symbol
terminator, e.g., (\ x x) would be construed as a list
containing 2, not 3 elements.
--d
Kent M Pitman
> Ah, but I was thinking of a lower-case greek lambda put in a decent
> position of my keyboard that I may use instead of the somewhat clumsy
> LAMBDA - without any extra effort on my part (such as reading up on
> character sets).
The Lisp Machine had a lambda character, which used the code in Lisp
Machine character space that was the same code as ASCII backspace,
for better or worse, so didn't show up well when the same file was viewed
on other platforms. But since Lambda is not in most people's character
sets even today, I suspect the same issues would apply--the problem is
it doesn't make good interchange. Ethnocentric though it may be, my
strong feeling is that it's not worth the effort for people to write in
other than the standard CL character set, which is widely available and
encourages portability.
Once, a LONG time ago (when I lived in Panama back in the early 1970's)
I visited a company that was doing programming in BASIC in Panama City and
I asked them if they resented that the BASIC keywords were in English.
The answer was: "Do you resent that the keywords for control of actions
in music are in Italian?" Part of me feels guilt that it's English and
not some other language, since English is my native language, but I've
worked with some guys in Portugal to make a multilingual programming system
and eventually gave up and focused on multilingual output instead, since
making a system that supports a billion different incompatible programming
styles really doesn't improve quality of life for programmers that much
and mostly makes it harder. I feel somewhat the same about a lambda
character--making life locally better for someone by a cool character at
the expense of interchange just isn't worth it. At least among we
programmers, who are few in number. The same energy is better spent on
making sure end users, of whom there are more, are well-served. And they
will not be well-served by interminable discussions about the syntax of
lambda expressions. Life is just too short.
JMO, YMMV, etc.
Erik Naggum
| CL and many Schemes use \ to escape the succeeding character, so the
| symbol \ would be unusably verbose (|\\|).
FWIW, \\ is sufficient.
#:Erik
William Tanksley
>William Tanksley <wtan...@dolphin.openprojects.net> wrote:
>>It's ridiculous, obviously, to claim that it's impossible to write a safe
>>macro in Lisp. GENSYM makes it all possible. The "problem" is that a
>>safe macro is a very complicated macro. My ideal would have safety be the
>>default, and anaphora require a brief workaround (certainly nothing
>>complicated).
>I believe Kent's point is that in Common Lisp, you can write a macro that's
>generally safe even without the complicated GENSYM logic. If the users of
>the macro are generally in a different package, and the variables you
>introduce aren't exported from your package or imherited from a package
>that the user's package is likely to :USE as well (e.g. the COMMON-LISP
>package) then a conflict is extremely unlikely.
Ah! Thank you. That makes a lot of sense, and is a very easy to follow
guideline. Thank you for explaining it.
I suppose it was silly of me to expect "On Lisp" to contain the correct
answer; I assumed that since it only talked about gensym as a solution,
that was the only solution. But "On Lisp" is a special-purpose book
(although I find it nice in a general way).
>If the macro is used within the defining package, it's easy to avoid
>inadvertent capture with reasonable naming conventions.
Absolutely.
>>You say that Lisp's macro system is "simpler". Presumably you mean
>>simpler than Scheme's, or perhaps simpler than defsafemacro. Yet it seems
>>to me that in order to make safe macros in Lisp, you have to be immensely
>>more careful and knowledgable about some huge complexities than you have
>>to be in Scheme.
>He may have been referring to the simplicity of the way the macro system
>works, not the way it's used.
I certainly appreciate that simplicity. It's not often found in modern
languages, and there aren't always good reasons for its omission.
>The Common Lisp macro system is trivial to
>describe: an ordinary function takes the input S-expression as a parameter
>and returns a new S-expression as a value, and that new expression is
>processed in place of the original. Anyone creating a Common Lisp
>implementation can implement the macro processor in seconds. The Scheme
>macro system is not so simple to describe.
The R5RS system is yet more complicated! I like it (I started out in
Scheme), but I find that I prefer Lisp's system.
Thanks again for your help, and everyone else who replied with similar help.
>Barry Margolin, bar...@bbnplanet.com
--
-William "Billy" Tanksley
Rolf-Thomas Happe
> The Lisp Machine had a lambda character, which used the code in Lisp
I was aware of this (or does my memory mix up lambda and yu-shiang
full fish, an entry of the Hacker's Jargon File?)
> and mostly makes it harder. I feel somewhat the same about a lambda
> character--making life locally better for someone by a cool character at
> the expense of interchange just isn't worth it. At least among we
> programmers, who are few in number. The same energy is better spent on
> making sure end users, of whom there are more, are well-served. And they
> will not be well-served by interminable discussions about the syntax of
> lambda expressions. Life is just too short.
I agree. My remark on LAMBDA was intended to communicate a piece of
half-serious wishful thinking:
(i) a genuine greek lambda substituting LAMBDA would be so nicely
... genuine.
(ii) a concise notation for anonymouus functions would help some
special forms to become regular first-class guys (procedures).
(Barry Margolin mentioned the recurrent discussions of IF
as function.) A defaultish greek lambda would weigh in some
keystrokes & letters less than LAMBDA does today, and would
thus increase conciseness (even concision).
Yet, these aren't practical concerns, and I invite everyone to ignore
them.
rthappe
Barry Margolin
Rolf-Thomas Happe <rth...@bonnie.mathematik.uni-freiburg.de> wrote:
> (ii) a concise notation for anonymouus functions would help some
> special forms to become regular first-class guys (procedures).
True. Smalltalk, Tcl, and Postscript are examples of languages that
essentially don't have many special operators, and do most control flow
using a concise syntax for creating thunks ([body] in both Smalltalk and
Tcl, I think) that are passed to ordinary functions.
Kent M Pitman
> Yet, these aren't practical concerns, and I invite everyone to ignore
> them.
I did use a lambda-character macro myself for a while and it was quite
fun and visually compelling (when viewed on the right machine :-),
so I do understand and appreciate your "interest". Thanks for clarifying
your posture on it as a practical matter.
Dorai Sitaram
Rolf-Thomas Happe <rth...@bonnie.mathematik.uni-freiburg.de> wrote:
>
>half-serious wishful thinking:
> (i) a genuine greek lambda substituting LAMBDA would be so nicely
> ... genuine.
> special forms to become regular first-class guys (procedures).
> as function.) A defaultish greek lambda would weigh in some
> keystrokes & letters less than LAMBDA does today, and would
> thus increase conciseness (even concision).
>them.
Does anyone know why the Greek letter lambda was chosen
by the mathematician(s) in the first place? Was it an
arbitrary choice?
--d