From: Erik Naggum
Subject: Re: To Paul Graham: Please put your books online.
Date: 
Message-ID: <3198932240187159@naggum.net>
* Thaddeus L Olczyk
> Should this continue, then employers who get wind may be hesitant to use
> Lisp on projects for fear that new developers may not be able to get
> materials needed to learn Lisp.

  This is a veiled threat, not a plea.  It is patently false that people
  who wish to learn Lisp are unable to get teaching material if Paul Graham
  does not provide his books to those who want to learn.  Obviously, Paul
  Graham learned Lisp enough to write those books before they existed.
  Many other Lisp programmers have learned Lisp without the aid of his
  books.  Paul Graham's books are _not_ the sine qua non they are touted to
  be.  My opinion is that his books "ANSI Common Lisp" is of very limited
  value to real programmers, perhaps even a disservice.  I doubt its
  tutorial value, too, as it does not in any way go into the "advanced"
  topics of exception handling and making an application failure resitant,
  which is hard work in all languages, but that, too, it easier in Common
  Lisp and better thought out.

  What happens to the people who "learn" Common Lisp?  Do they leave the
  language after a while?  Do they ever build real applications with it?
  do they ever have to deal with the traumatic real world in Common Lisp,
  or do they only deal with simple stuff in a protected environment?

  Common Lisp (environments) offer incredibly powerful means of dealing
  with unexpected situations, including jumping into the debugger,
  exception handling par excellence, dynamic updating of code and classes.
  Not all people appreciate this.  Some people appreciate the availablity
  of non-trivial algorithms and data types, and would enjoy the vast array
  of pre-written code in languages such as C++, Java, and Perl.  Common
  Lisp is a way of thinking, not "just a tool", which is how many see any
  programming language, preferring to think in some way they may believe is
  unrelated to their specific language.  Paul Graham's books did not offer
  much, if anything, in this vein.  While On Lisp was clever, it offered
  only one man's view and ended there.  Did anyone write any clever code on
  their own after reading that book, which they proceeded to share with
  others (in any way: for-profit, non-profit, give-away)?  Or did they only
  read it?

  The uncomfortable question is: Did you _learn_ anything from his books?
  If so, why can you not write it down on your web pages and talk about it
  in the newsgroup instead of clamoring for copies of the book you learned
  from as if the knowledge and understanding you have gained is unable to
  reproduce itself?

  An uncomfortable answer is that the Common Lisp community is hostile to
  creativity.  People argue that Lisp is dead, but it is the Lispers who
  are dead.  With a few exceptions, people who use Lisp have given up, and
  they only require, they do not provide.  Many Lisp programmers demand
  that sockets and multiprocessing should be _standardized_ before they
  want to use it, which penalizes creativity like nothing else.  Many Lisp
  programmers think it sucks to interface with other (inferior) languages,
  some in general, some because it isn't standardized, some because they
  fail to understand how software is organized and want a perfect world.

  Who among the avid readers of Paul Graham's books are prepared to exceed
  their teacher?  I would claim that a teacher who does not produce at
  least one student who excel way beyond the teacher's level is a failure.
  This is why it is so hard to write good textbooks in a language that is
  _already_ the result of many students excelling beyond their teachers and
  why it is so easy to write good textbooks in a language that beyond which
  almost anyone can go, such as Scheme.  The Lisp world does not need more
  Scheme texts, even if they cover Common Lisp.  It needs more Common Lisp
  texts that show how Common Lisp is _still_ way ahead of the pack, that it
  rises tall like a sequoia in an underbrush of weeds competing for the
  attention of people who fail to look up when they bump into the huge tree
  and instead walk around it, not believing those who told them had just
  missed something.  Like the sequoia, Common Lisp survives the brush fires
  and has built-in means of coming out on top.  _That_ is what should be
  taught in Lisp texts, not "how to disguise a sequoia among the weeds".

#:Erik
-- 
  Travel is a meat thing.

From: Steven L. Collins
Subject: Re: To Paul Graham: Please put your books online.
Date: 
Message-ID: <9ds96h$gla$1@slb3.atl.mindspring.net>
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...


> * Thaddeus L Olczyk
> > Should this continue, then employers who get wind may be hesitant to use
> > Lisp on projects for fear that new developers may not be able to get
> > materials needed to learn Lisp.
>
>   This is a veiled threat, not a plea.  It is patently false that people
>   who wish to learn Lisp are unable to get teaching material if Paul
Graham
>   does not provide his books to those who want to learn.  Obviously, Paul
>   Graham learned Lisp enough to write those books before they existed.

I'll bet he was using "Lisp" by Winston and Horn.  I think the 3rd edition
is an OK reference and it's still in print.  But there is the strange
reference to Gold Hill CL.  Is Gold Hill still selling Golden Common Lisp?

------------- Snip ----------

>   The uncomfortable question is: Did you _learn_ anything from his books?
>   If so, why can you not write it down on your web pages and talk about it
>   in the newsgroup instead of clamoring for copies of the book you learned
>   from as if the knowledge and understanding you have gained is unable to
>   reproduce itself?
>
>   An uncomfortable answer is that the Common Lisp community is hostile to
>   creativity.  People argue that Lisp is dead, but it is the Lispers who
>   are dead.  With a few exceptions, people who use Lisp have given up, and
>   they only require, they do not provide.  Many Lisp programmers demand
>   that sockets and multiprocessing should be _standardized_ before they
>   want to use it, which penalizes creativity like nothing else.  Many Lisp
>   programmers think it sucks to interface with other (inferior) languages,
>   some in general, some because it isn't standardized, some because they
>   fail to understand how software is organized and want a perfect world.

I'm trying to become a *LISP Programmer* because I think I'm starting to see
the forest, not just a bunch of trees.

----------Snip-----------
>   This is why it is so hard to write good textbooks in a language that is
>   _already_ the result of many students excelling beyond their teachers
and
>   why it is so easy to write good textbooks in a language that beyond
which
>   almost anyone can go, such as Scheme.  The Lisp world does not need more
>   Scheme texts, even if they cover Common Lisp.  It needs more Common Lisp
>   texts that show how Common Lisp is _still_ way ahead of the pack, that
it
>   rises tall like a sequoia in an underbrush of weeds competing for the
>   attention of people who fail to look up when they bump into the huge
tree
>   and instead walk around it, not believing those who told them had just
>   missed something.

 One thing that has been puzzling me over the last year is why LISP is not
more popular?  It seems to be significantly more powerful then C/C++.  I
would have to say that the demo version of "Allegro CL" I tried,  was the
"Most Advanced Development Environment" I have ever seen or tried.  I'm
currently saving my $ to buy a copy.  It makes Visual C++ look like a toy.
 Why is Scheme and C++ preferred over Lisp at the CS-101 level.  Is it just
marketing skill? The lack of it at companies like Franz and Xanalys. Or is
it more a fad like Disco Music :-)

 I do wish I could get my hands on more Lisp literature.  But as you seem to
indicate just write more programs and use it more.

Steven
From: Joseph Dale
Subject: Re: To Paul Graham: Please put your books online.
Date: 
Message-ID: <3B01AD41.7D218CA@uclink4.berkeley.edu>
"Steven L. Collins" wrote:
> 
> "Erik Naggum" <····@naggum.net> wrote in message
> ·····················@naggum.net...
> 
> > * Thaddeus L Olczyk
> > > Should this continue, then employers who get wind may be hesitant to use
> > > Lisp on projects for fear that new developers may not be able to get
> > > materials needed to learn Lisp.
> >
> >   This is a veiled threat, not a plea.  It is patently false that people
> >   who wish to learn Lisp are unable to get teaching material if Paul
> Graham
> >   does not provide his books to those who want to learn.  Obviously, Paul
> >   Graham learned Lisp enough to write those books before they existed.
> 
> I'll bet he was using "Lisp" by Winston and Horn.  I think the 3rd edition
> is an OK reference and it's still in print.  But there is the strange
> reference to Gold Hill CL.  Is Gold Hill still selling Golden Common Lisp?
> 

It appears that they are: http://www.goldhill-inc.com/ has some
offerings. Interestingly, I think there's more to the relationship
between "Lisp" and Gold Hill than that reference. I recently found a
used copy (c. 1991 - it's of purely historical value I guess, but hey,
it only cost 50 cents) of the student version of Golden Common Lisp. The
package has the same art as the cover of "Lisp", and there's some sort
of online tutorial included based on the text of "Lisp".

Joe
From: raj
Subject: Re: To Paul Graham: Please put your books online.
Date: 
Message-ID: <ish3gtgrnjog97cah0hophl61pgg46s1oc@4ax.com>
>I'll bet he was using "Lisp" by Winston and Horn.  I think the 3rd edition
>is an OK reference and it's still in print.  But there is the strange
>reference to Gold Hill CL.  Is Gold Hill still selling Golden Common Lisp?

It exists. 
It is just very poorly marketed.
ie: almost no web presence, no participation by staff in the lisp
newsgroups, no free limited demo. In addition , at 2000$ + it is a bit
pricy.

See:
http://www.goldhill-inc.com/developer.html
From: Larry Elmore
Subject: Re: To Paul Graham: Please put your books online.
Date: 
Message-ID: <3B01E018.E4E98123@home.com>
Erik Naggum wrote:
> 
> * Thaddeus L Olczyk
> > Should this continue, then employers who get wind may be hesitant to use
> > Lisp on projects for fear that new developers may not be able to get
> > materials needed to learn Lisp.
> 
>   This is a veiled threat, not a plea.

It's not even remotely a "threat." It's merely a warning, and there's a
big difference between the two. As it is, I think the warning _is_
faintly ridiculous.

>  It is patently false that people
>   who wish to learn Lisp are unable to get teaching material if Paul Graham
>   does not provide his books to those who want to learn.  Obviously, Paul
>   Graham learned Lisp enough to write those books before they existed.
>   Many other Lisp programmers have learned Lisp without the aid of his
>   books.

True, but it is equally obviously that many people have found them
valuable. I haven't read "On Lisp" so I can't comment on it, but I found
"ANSI Common Lisp" to be a good introduction to Lisp. There are
certainly _worse_ books out there. What would you recommend, Erik?

Larry
From: ········@hex.net
Subject: Re: To Paul Graham: Please put your books online.
Date: 
Message-ID: <FqnM6.11746$iC1.401280@news6.giganews.com>
Larry Elmore <········@home.com> writes:
> Erik Naggum wrote:
> > * Thaddeus L Olczyk
>>> Should this continue, then employers who get wind may be hesitant
>>> to use Lisp on projects for fear that new developers may not be
>>> able to get materials needed to learn Lisp.

>> This is a veiled threat, not a plea.

> It's not even remotely a "threat." It's merely a warning, and
> there's a big difference between the two. As it is, I think the
> warning _is_ faintly ridiculous.

I'm not sure "warning" is even quite right.

The word "hesitant" seems pretty appropriate.  

If there's not an active deployment of literature about a language, it
seems not unreasonable to think that interest in that language may be
waning, which will discourage its use.

>>It is patently false that people who wish to learn Lisp are unable
>>to get teaching material if Paul Graham does not provide his books
>>to those who want to learn.  Obviously, Paul Graham learned Lisp
>>enough to write those books before they existed.  Many other Lisp
>>programmers have learned Lisp without the aid of his books.

> True, but it is equally obviously that many people have found them
> valuable. I haven't read "On Lisp" so I can't comment on it, but I
> found "ANSI Common Lisp" to be a good introduction to Lisp. There
> are certainly _worse_ books out there. What would you recommend,
> Erik?

The main text that is readily available these days seems to be
Norvig's "PAIP," which, it seems to me, is somewhat _better_ than
either of Graham's books.

I would suggest the thought that it would _not_ be an utterly horrible
thing that Graham's first two books are getting decreasingly available
if there were something new in the wings.  

I'm sure it would be instructive if Graham wrote a _new_ book
describing the sorts of (language-oriented) techniques used to make
the Yahoo! Store work.  A book presenting ways of building Lisp-based
web applications could provide all sorts of opportunities to talk
about interesting and overall instructive techniques.  Probably would
be more practical than Yet Another Piece on anaphoric macros.
-- 
(reverse (concatenate 'string ····················@" "454aa"))
http://vip.hex.net/~cbbrowne/lisp.html
Rules of the Evil Overlord #73. "I will not agree to let the heroes go
free if they  win a rigged contest, even though  my advisors assure me
it is impossible for them to win." <http://www.eviloverlord.com/>
From: Biep @ http://www.biep.org/
Subject: Re: To Paul Graham: Please put your books online.
Date: 
Message-ID: <9fl2hm$4mfh2$1@ID-63952.news.dfncis.de>
<········@hex.net> wrote in message
···························@news6.giganews.com...
> The main text that is readily available these days
> seems to be Norvig's "PAIP," which, it seems to me,
> is somewhat _better_ than either of Graham's books.

While PAIP is a great book, and can be used as an introduction to Common
Lisp, it wasn't meant as such, and in fact the code in the book is
inetntionally fairly basic, with a few exceptions, such as the stuff on
macros (which, by the way, is mainly complex because writing a serious
macro in CL involves a lot of "fighting the system").

Someone who has worked his or her way through PAIP will have a decent
knowledge of basic AI approaches, but still needs to learn a lot both about
Common Lisp itself and about Lisp programming techniques that have not or
barely been touched on.

On the other hand: someone who enjoyed working through PAIP is almost
certainly someone who is well-equipped to learn these things.

I don't know Graham's books, so I cannot compare them.

--
Biep
Reply via http://www.biep.org
From: Pierre R. Mai
Subject: Macro-writing in CL (was something else entirely)
Date: 
Message-ID: <87g0ddzv3r.fsf_-_@orion.bln.pmsf.de>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> While PAIP is a great book, and can be used as an introduction to Common
> Lisp, it wasn't meant as such, and in fact the code in the book is
> inetntionally fairly basic, with a few exceptions, such as the stuff on
> macros (which, by the way, is mainly complex because writing a serious
> macro in CL involves a lot of "fighting the system").

That remark made me interested:  In what way do you feel that writing
(serious) macros in CL involves 'a lot of "fighting the system"'?
This seems to imply that CL is actively "resisting" your writing of
the macro in some form, which would imply that CL is in some ways
unsuited to writing list-transformation programs.  Could you
elaborate?

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fnf97$52id2$1@ID-63952.news.dfncis.de>
"Pierre R. Mai" <····@acm.org> wrote in message
······················@orion.bln.pmsf.de...
> In what way do you feel that writing (serious) macros in CL
> involves 'a lot of "fighting the system"'?

O.K.  I take it you are an experienced macro writer.

(1) People like you and me have come to grips with the intricacies of macro
writing, know the pitfalls and how to avoid them, and may even have the
status of "macro guru".  This is somewhat like Mel in the story
(http://www.brabandt.de/html/jargon_49.html).  I think the very fact that
there are macro gurus indicates that there is a problem: the basic notion
of a macro is very simple, yet it is not trivial for a novice to go and
write good macros.

(2) Macros are (or should be) about meaning one thing when you say
another -- not necessarily about transformations, even though the notions
come close.  (To appreciate the difference, see what C macros can do that
they shouldn't..)  Let me just give a few examples:

There is a subtle but fundamental difference between the notions of 'fresh
variable' and '(gensym)'.  The latter is a kluge to arrive at the former
(or the right thing to do in other contexts, of course).

There is a difference between 'the list function' and '(list ...)'.  CLtL2
has 'solved' the resulting problem by requiring that no built-in function
can be redefined, but that is of course a weakness bid.

Lisp has fought hard to get rid of (default) dynamic scoping, but in macros
this is still the default.  If your macro references a variable X, it just
grabs whatever X happens to be available at the location where the macro is
used.  Like dynamic scoping for lambdas, people who have gotten used to
that tend to like it, and indeed can proffer a whole battery of situations
where this 'feature' can be exploited -- again the guru phenomenon.
Normally you mean 'this variable' but have to write 'X', again not quite
the same thing.  As with functions, lexical scoping (referential
transparency) should be the default, with an option for dynamic scoping.

(3) So since the macro writer wants to state "whenever I say this I MEAN
that", but the system wants to hear "whenever you say this, I should assume
that you SAID that", macro writing necessarily involves fighting the
system.  It is a lot like legalese: a lawyer is also a guru in bringing a
meaning across in a system that tends to look at texts, but it involves
non-trivial phrasings, and often a lot more text than one might have
thought.  If a non-guru draws up a legal document, it is likely there are
loopholes.

Does that help?  Again, if you are familiar with the system, the
"macrolese" may come naturally, and even appear obvious, and definitely
prove exploitable in ways that a "correct" solution would not be -- again
the comparison with lawyers comes to mind :-)

--
Biep
Reply via http://www.biep.org
From: Janis Dzerins
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <878zj4vco0.fsf@asaka.latnet.lv>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> "Pierre R. Mai" <····@acm.org> wrote in message
> ······················@orion.bln.pmsf.de...
> > In what way do you feel that writing (serious) macros in CL
> > involves 'a lot of "fighting the system"'?
> 
> O.K.  I take it you are an experienced macro writer.
> 
> (1) People like you and me have come to grips with the intricacies
> of macro writing, know the pitfalls and how to avoid them, and may
> even have the status of "macro guru".

Pleas call me "eating guru". I eat every day. I even use that super
cool tool called spoon.

If you call everyone who has learned to use something a "guru" then I
think this word is overloaded (in the C++ sense).

> I think the very fact that there are macro gurus indicates that
> there is a problem:

Could you please state once more for me what exactly is "macro guru"?

> the basic notion of a macro is very simple, yet it is not trivial
> for a novice to go and write good macros.

It is not trivial for *anybody* to make something of quality without
learning how to do it. Even if the tools are simple and have taken a
lot of time to become such.

> (2) Macros are (or should be) about meaning one thing when you say
> another

Macro is a tool -- the one that lets you, as a programmer, extend the
language. It's not just a text replacing tool (although you may want
use it as such). Looks like you want something and think it is macros
but it ain't.

> There is a subtle but fundamental difference between the notions of
> 'fresh variable' and '(gensym)'.  The latter is a kluge to arrive at
> the former (or the right thing to do in other contexts, of course).

It may be a kludge for you. It does not mean that it is a kludge for
other programmers. It might also be that macros are not suitable for
the task you want to use them for and thus may look like a
kludge. Might be that you just have not learned and do not understand
them.

If you have invented a way to make macros better please show it to
us. I'm sure everyone here will appreciate it. Until then we're all
using what has worked until now.

> There is a difference between 'the list function' and '(list ...)'.

Can't understand what you're talking about.

> CLtL2 has 'solved' the resulting problem by requiring that no
> built-in function can be redefined, but that is of course a weakness
> bid.

In what way it is a weakness?

If you write a program that uses LIST function and then someone else
changes that function, how do you expect your program to work?

> Lisp has fought hard to get rid of (default) dynamic scoping, but in
> macros this is still the default.

I'd say macros have no different scoping.

> If your macro references a variable X, it just grabs whatever X
> happens to be available at the location where the macro is used.

Yes. And thats what it is supposed to do (although I don't like the
term "grabs").

> Like dynamic scoping for lambdas, people who have gotten used to
> that tend to like it, and indeed can proffer a whole battery of
> situations where this 'feature' can be exploited -- again the guru
> phenomenon.

I don't completely understand what you mean by "dynamic scoping for
lambdas". But I can't see any guru phenomenon here.

> Normally you mean 'this variable' but have to write 'X', again not
> quite the same thing.

Can't follow you without a piece of code.

> As with functions, lexical scoping (referential transparency) should
> be the default, with an option for dynamic scoping.

Talking about language design?

I'd say -- if there's something missing in Common Lisp for you, go
write it. But it would most probably require writing macros which
don't quite understand.

> (3) So since the macro writer wants to state "whenever I say this I MEAN
> that",

I'd say it's more like "whenever I say this I MEAN this".

> but the system wants to hear "whenever you say this, I should assume
> that you SAID that", macro writing necessarily involves fighting the
> system.

There's no fighting. The system does exactly what you tell it to do,
according to The Standard.

> Again, if you are familiar with the system, the "macrolese" may come
> naturally, and even appear obvious, and definitely prove exploitable
> in ways that a "correct" solution would not be

Macros *are* a correct solution to correct problems. If you're afraid
to familiarize yourself with the system it looks like your problem not
Lisp's.

-- 
Janis Dzerins

  If million people say a stupid thing it's still a stupid thing.
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fnru7$56c8b$1@ID-63952.news.dfncis.de>
> > = me ("Biep @ http://www.biep.org/")

Let me start by clarifying that I am NOT complaining about anything, I was
simply explaining why certain code was somewhat complex, and happened to use
"fighting the system" in my explanation.  In particular, I am NOT saying that
anything should change.


"Janis Dzerins" <·····@latnet.lv> wrote in message
···················@asaka.latnet.lv...
> If you call everyone who has learned to use something a "guru" then I
> think this word is overloaded (in the C++ sense).

I don't.  I mean that people walk up to me, even though they are decent
programmers, to have me get wrinkles out of their macro.  Of if they don't walk
up to me, I can often construct a context in which their macro doesn't do what
they had intended it to do.

> Macro is a tool -- the one that lets you, as a programmer, extend the
> language. It's not just a text replacing tool (although you may want
> use it as such). Looks like you want something and think it is macros
> but it ain't.

I know what a macro is, and how to write them.  I was simply explaining what I
meant with "fighting the system".

> If you have invented a way to make macros better please show it to
> us. I'm sure everyone here will appreciate it. Until then we're all
> using what has worked until now.

Of course.  A lot of research is going on (more in the Scheme community than in
the CL community as far as I am aware), but I don't think the final solution has
been found yet.  Obviously, until that happens we all happily go on hacking.

> > There is a difference between 'the list function' and '(list ...)'.
> Can't understand what you're talking about.

About someone calling your macro in the context of an (flet ((list ..)) ..).
CLtL2 saves you here, but if instead of 'list' it were a function you had
defined yourself, you would still be bitten.  Lexical scoping would have saved
you here, would have allowed you to write a protected lexical scope that would
also have saved you from redefinitions.

> In what way it is a weakness?

If doing something turns out to go wrong, and it can be fixed, I consider it a
weakness simply to forbid doing it.  It is a bit of brittleness in an otherwise
sturdy language.  I don't want to see CL turn into a "you cannot do that"
language -- we have already enough of those.

> If you write a program that uses LIST function and then someone else
> changes that function, how do you expect your program to work?

By wrapping a scope around your functions that protects the original definition
of list.

> > If your macro references a variable X, it just grabs whatever X
> > happens to be available at the location where the macro is used.
>
> Yes. And thats what it is supposed to do (although I don't like the
> term "grabs").

..and that's dynamic scoping.  An X in a lambda doesn't behave that way: it
always refers to the X in the context in which the lambda was defined.  I have
been way too much in the discussion of dynamic vs. lexical scoping for lambda's,
and endlessly heard exactly the phrase you use "And that's what it is supposed
to do", and don't have the energy any more to go into that discussion, sorry.
Nothing personal.  You might want to check
http://www.acm.org/pubs/citations/proceedings/lfp/62678/p86-bawden/ if you are
an ACM member.  (If you are not, you might find a working version of that paper
at ftp://altdorf.ai.mit.edu/pub/scheme-reports/synclo.ps).

> There's no fighting. The system does exactly what you tell it to do,
> according to The Standard.

In that case writing VB is no fighting either..  :-)

--
Biep
Reply via http://www.biep.org
From: Marco Antoniotti
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <y6c1yow9y4u.fsf@octagon.mrl.nyu.edu>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

	...

> > If you have invented a way to make macros better please show it to
> > us. I'm sure everyone here will appreciate it. Until then we're all
> > using what has worked until now.
> 
> Of course.  A lot of research is going on (more in the Scheme
> community than in the CL community as far as I am aware), but I
> don't think the final solution has been found yet.  Obviously, until
> that happens we all happily go on hacking.

Of course in Scheme you have to "fight the (impoverished) system" much
much more than in CL, just to make it usable as a whole.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fo4o6$565ce$1@ID-63952.news.dfncis.de>
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
····················@octagon.mrl.nyu.edu...
> Of course in Scheme you have to "fight the (impoverished) system"
> much much more than in CL, just to make it usable as a whole.

Well, if you stick to the standard, it is not so much fighting as simply being
unable to.  (O.K., CPS style macros might be considered fighting the system, but
then CPS is popular in Scheme circles..)

Fortunately virtually every implementation goes well beyond the standard, but it
is a shame that decent macros are often necessarily unportable.

I think that is inherent in the different approaches: CL wants something that
works, and wants it now, and Scheme wants the right thing or nothing - and often
that is nothing.

--
Biep
Reply via http://www.biep.org
From: Marco Antoniotti
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <y6cy9r48h93.fsf@octagon.mrl.nyu.edu>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> "Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
> ····················@octagon.mrl.nyu.edu...
> > Of course in Scheme you have to "fight the (impoverished) system"
> > much much more than in CL, just to make it usable as a whole.
> 
> Well, if you stick to the standard, it is not so much fighting as
> simply being unable to.  (O.K., CPS style macros might be considered
> fighting the system, but then CPS is popular in Scheme circles..)
> 
> Fortunately virtually every implementation goes well beyond the
> standard, but it is a shame that decent macros are often necessarily
> unportable.
> 
> I think that is inherent in the different approaches: CL wants something that
> works, and wants it now, and Scheme wants the right thing or nothing
> - and often that is nothing.

Excellent point.  Although I'd go as far as saying, that most of the
time, what works (in CL) also happens to be "the rigth thing".

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Erik Naggum
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <3200914634726937@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> Let me start by clarifying that I am NOT complaining about anything [...]

  Hmmm.

> I mean that people walk up to me, even though they are decent
> programmers, to have me get wrinkles out of their macro.  Of if they
> don't walk up to me, I can often construct a context in which their macro
> doesn't do what they had intended it to do.

  Seems to me you are indeed complaining instead of solving the problem.
  If you know this stuff so well (which I have yet to see evidence of),
  either your communication skills towards the people you are helping is
  lacking, or they fail to learn enough from you.  Write a paper on proper
  macro-writing and publish it.  From what I have seen so far, you should
  expect criticism of your narrow view of their uses and purposes.

> I know what a macro is, and how to write them.

  I am a fairly good marksman, and after having seen little improvement in
  my shooting in the past couple months, I worried to a fellow marksman,
  much, much better than me, that I had reached the apex of my skills.  He
  looked amused and said he had experienced the same thing several times
  and always needed advice from better marksmen to change some of the
  things he did not think needed improvement, some of them rather dramatic.
  One of the great things about truly useful skills is that there is always
  more to learn.  Optimization has the drawback that if you optimize the
  wrong way, for the wrong purpose, you end up being good at something that
  is simply _wrong_ to be good at.  If you still insist on improving, you
  may in fact get worse to an objective eye, since you fail to reach the
  goal.  (This part is fortunately impossible in shooting.  It is such an
  easy way to get feedback.)

> Of course.  A lot of research is going on (more in the Scheme community
> than in the CL community as far as I am aware), but I don't think the
> final solution has been found yet.  Obviously, until that happens we all
> happily go on hacking.

  In my view, the final solution on macros has already been found.  Scheme
  folks are continuing to "research" down the wrong path, as they have for
  many, many years.  They are like the "doctors" of the past who thought
  illness was in the blood, and go on with their "research" despite the
  discovery of penicillin elsewhere.

> About someone calling your macro in the context of an (flet ((list ..)) ..).

  The problems in Scheme are not the problems in Common Lisp.  If a Scheme
  jerk does that in Common Lisp, he breaks the rules, written and unwritten
  and should not blame the language for his ignorance.

  "Doctor, doctor, it hurts when I make this contorted movement."
  "So don't do it."

> CLtL2 saves you here

  You know, one of the symptoms of your lack of sufficient effort is that
  you think CLtL2 is the authoritative reference.  You may not be aware of
  this, but ANSI X3.226 Common Lisp has been issued, in fact was issued on
  1994-12-15.  It is now the authoritative reference on Common Lisp.  You
  can find hypertext versions on the Net if you too cheap to buy the real
  thing from ANSI.

> but if instead of 'list' it were a function you had defined yourself, you
> would still be bitten.

  But why should the macro be using it?  Obviously, the macro references an
  environment known to it, and draws on functions that are well-defined in
  it.  If you change those with flets, you should be fully aware of the
  consequences.  Incidentally, if you feel that this is such a drag, the
  rule that you should not redefine functions in the common-lisp package is
  not an arbitrary restriction.  It is good advice never to redefine a
  function locally that has a global, _published_ definition.  If you _do_
  do so, it is for the obvious side effect that you blame "gurus" for.

  Does this mean that the application programmer should be mortally afraid
  of screwing with somebody's names, like he would be in a one-namespace,
  no-packages language like Scheme?  Not at all.  Packages have published
  and unpublished symbols, mind you, so if you take care to review the
  published symbols in a package you have used, you follow the same rule
  for _any_ package you use as you do for the common-lisp package.  Only
  the standard could not have mandated the same thing for your symbols as
  it does for the standard symbols.

  I think the rule is really, really simple: If the symbol is not in your
  own package, be very cautious.  Now, there are some "problems" with the
  package symbol in that it would have been lovely if the various values of
  a symbol could be treated differently, but this quickly leads to serious
  problems, too.

  Some other languages require serious ownership protocols for objects.
  Common Lisp requires an ownership protocol for symbols, instead.  The
  former are runtime concerns..  The latter are read-time concerns and
  should be covered by interprogrammer communication, a.k.a. documentation.

> Lexical scoping would have saved you here, would have allowed you to
> write a protected lexical scope that would also have saved you from
> redefinitions.

  Really?  Are you sure you understand what lexical and dynamic scope are
  all about?  It sure looks like you have skipped a few classes on this.

> If doing something turns out to go wrong, and it can be fixed, I consider
> it a weakness simply to forbid doing it.

  An amazing attitude.  How is this reflected in your view of society in
  general?  Or are you one of those bondage-and-discipline programmers who
  want static type checking, class-owned methods, etc, too?  If so, why do
  you bother with Common Lisp at all?

> It is a bit of brittleness in an otherwise sturdy language.

  It is called "flexibility and responsibility".  It can be bent, but if
  you bend it out of shape or break it, that is your responsibility.  If
  you set up the rules so that you need never bend them, somebody else will
  feel imprisoned in your language.  I can say right now that I would not
  use the language you think is so much better than Common Lisp.

> I don't want to see CL turn into a "you cannot do that" language -- we
> have already enough of those.

  Precisely, but you argue very strongly in favor of just that.  Exactly
  like a politician who loves freedom as long as everybody does what he
  thinks is best for them.  Freedom in a society is not a question of what
  you can do within the rules, it is a question of what happens to those
  who want to break or change the rules because they think the rules are
  wrong.  Macros in Common Lisp makes it possible for freedom fighters to
  write their _own_ rules.  Some people are incredibly emotionally opposed
  to such a concept, calling it "anarchy" and all sorts of negative things.
  I read you to be such a person.

> By wrapping a scope around your functions that protects the original
> definition of list.

  This may be done with a code-walking macro.  Go write it.

> > > If your macro references a variable X, it just grabs whatever X
> > > happens to be available at the location where the macro is used.
> >
> > Yes. And thats what it is supposed to do (although I don't like the
> > term "grabs").
> 
> ..and that's dynamic scoping.

  Bzzzzzt!  Wrong!

> An X in a lambda doesn't behave that way: it always refers to the X in
> the context in which the lambda was defined.

  Which lambda are you talking about now?  Are you perchance unaware of the
  effect of special declarations, which do in fact make real dynamic scope?

> I have been way too much in the discussion of dynamic vs. lexical scoping
> for lambda's, and endlessly heard exactly the phrase you use "And that's
> what it is supposed to do", and don't have the energy any more to go into
> that discussion, sorry.  Nothing personal.  You might want to check
> http://www.acm.org/pubs/citations/proceedings/lfp/62678/p86-bawden/ if
> you are an ACM member.  (If you are not, you might find a working version
> of that paper at ftp://altdorf.ai.mit.edu/pub/scheme-reports/synclo.ps).

  Precisely.  You want syntactic closures.  You can have that in addition
  to macros.  You know how you can get that, do you not?  If not, let me
  remind you of how to write macros: Use copy-symbol for all symbols
  referenced in the macro body, and refer to the uninterned symbols you
  have created.  Pretty easy to do.  I suggest you show us how to do it,
  since you (1) know how to write macros, and (2) need this.  If you do
  not, I just conclude that you are one of those people who have a Scheme
  brain that cannot deal with Common Lisp.  There are a lot of those in the
  Scheme community.  It is one of the reasons I want such Scheme people to
  go to hell.  Fortunately, they are doing it on their own, anyway.  It is
  also one of the reasons I no longer consider Scheme a Lisp.

#:Erik
-- 
  Travel is a meat thing.
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fq2bc$5hrsr$1@ID-63952.news.dfncis.de>
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
>   I read you to be such a person.

Yes Erik, you have already shown clearly enough that you cannot read.

If you could, I could give you some hints on reading, like the fact that there
is a semantics phase between input syntax and reply syntax.
I really hope one day you will get to the level that you can read and understand
what I wrote, and see that you are not addressing at all what I am talking
about.

--
Biep
Reply via http://www.biep.org
From: Erik Naggum
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <3201180287961785@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> If you could, I could give you some hints on reading, like the fact that there
> is a semantics phase between input syntax and reply syntax.
> I really hope one day you will get to the level that you can read and understand
> what I wrote, and see that you are not addressing at all what I am talking
> about.

  I believe in the reciprocality of advice.  This means that advice that
  obviously only work one way ("you should" and "I should" are dissimilar)
  are completely devoid of meaning and are instead pure acts of aggression.

  You have shown me that you do not listen to what anybody else writes at
  all.  This means that "read and understand what I wrote" means only one
  thing: "agree with me".  This is probably also why you also believe that
  disagreement has anything to do with the criticism you receive.

  Now, please tell me, in simple words that you think I can understand,
  what are you posting here in order to achieve?  What is your goal?  When
  would you be satisfied to have achieved that goal?  Is there a measure of
  partial success?  Of incremental improvement towards any goal?

  From what I read of your posts, you are here to defend your own _person_.
  It is not your _ideas_ that you defend, it is _your_ ideas.  That is not
  a very healthy premise to hold when you start posting to USENET.  Ideas,
  both good and bad, get beaten up.  If you mix _yourself_ into all this,
  you get hurt.  Any ideas you post on USENET must of necessity be ideas
  that you can afford to see trashed, and not only ideas, anything you say
  at all _must_ be worth so little that anybody, anywhere can say whatever
  they want about it and it would not possibly affect your _person_.  This
  is usually easy, but some people turn out to be so personally involved in
  what they post that they feel as if they are under personal attack even
  when only what they have _said_ is under attack, if anything, and then it
  may turn pretty nasty, especially if they are the religiously motivated
  kind that want to expel "evil" and can do anything they want to fight it,
  including _much_ worse things than anybody ever did to them.  Something
  in the human psyche shows up in people whose ethics only work when they
  are treated _well_ by others: they go insane and become the most unethical
  people you can think of when they are "mistreated", a judgment call they
  make entirely on their own.  Fairweather ethics is useless.  Your _real_
  ethics is the one you reveal when you are angry, _really_ angry.  I think
  it is useless to talk about ethics among well-behaved people to begin
  with -- it is what we do when people are _not_ well-behaved (to us) that
  matters.  The kind of person who goes mad with rage and starts insulting
  people with ridiculously malplaced accusations that have _nothing_ to do
  with the topic at hand is but a curious, yet irrelevant, lunatic.

  For instance, anyone who tells others they cannot read probably have had
  a deeply personal relationship with reading disorders.  It was very bad
  for them, so it must hurt for others, too.  If people share the same
  problem, say suffering through the ambarrassments of remedial reading in
  grade school, the feeling is immediate and an amotional response follows
  automatically.  However, if you try this to someone whose reading skills
  far exceed your own, who read better than most adults at age 4, who reads
  snd writes several different languages, who very seldom publishes spelling
  mistakes and who turns to a dictionary to _learn_ new words and to make
  sure they are understood correctly, it is only laughable evidence of a
  loser's pathetic attempt to make his opponent as bad as himself.  A bad
  reader who tries in vain to insult others by being worse than him, which
  would have been a very grave insult indeed, only reveals his own problem.
  I think this is amusing in the most obvious cases, like this one.  But I,
  too have hot spots.  _Very_ few people have figured out which they are,
  but "your ideas are bad/stupid/whatever" is _not_ among them, but I do
  think that those who cannot accept such trashing of their ideas in public
  should lock themselves in their private chambers and swallow the key.

  It may be that the concepts of "private" and "public" have deteriorated
  to the point where it no longer makes sense to talk about it at all, but
  I want to believe that there is still a distinction and that those who
  confuse the two are and will forever be _wrong_ in doing so.

  Using a phony identification on your USENET posts is not a good way to
  separate private and public, especially when you are so sensitive about
  private matters that you have gone out of your way to make it impossible
  to attach them to any real person, anyway.

#:Erik
-- 
  Travel is a meat thing.
From: Erik Naggum
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <3200908738061425@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> (1) People like you and me have come to grips with the intricacies of macro
> writing, know the pitfalls and how to avoid them, and may even have the
> status of "macro guru".  This is somewhat like Mel in the story
> (http://www.brabandt.de/html/jargon_49.html).  I think the very fact that
> there are macro gurus indicates that there is a problem: the basic notion
> of a macro is very simple, yet it is not trivial for a novice to go and
> write good macros.

  How can you both invent _and_ lament the macro guru at the same time?
  There is no such thing as a macro guru.  There are, however, macrophobes.

> (2) Macros are (or should be) about meaning one thing when you say
> another -- not necessarily about transformations, even though the notions
> come close.  (To appreciate the difference, see what C macros can do that
> they shouldn't..)  Let me just give a few examples:

  Macros are in fact implemented as transformations.  What you make of them
  is up to you.  Ingenious use of macros can make some things very easy to
  understand.  Idiot use of macros make things harder to understand.  What
  else is new?  Incidentally, every "should be" betrays an agenda.  Before
  things "should be", study what they _are_.  Your problem is that you
  started to "should be" before you understood how things are.  (This has
  been evident for a long time, by the way.)

> There is a subtle but fundamental difference between the notions of 'fresh
> variable' and '(gensym)'.  The latter is a kluge to arrive at the former
> (or the right thing to do in other contexts, of course).

  So you choose to rebel against the obvious, and call things "kluge" that
  are simply means of achieving something you need.  What else is new?
  Rebels _are_ usually clueless.  This is how we do these things.  If you
  do not like it, invent something better.  Criticizing without improvement
  is just so much useless whining.

> There is a difference between 'the list function' and '(list ...)'.
> CLtL2 has 'solved' the resulting problem by requiring that no built-in
> function can be redefined, but that is of course a weakness bid.

  Could you try to _explain_ your mindset instead of giving examples that
  make sense only to yourself?

> Lisp has fought hard to get rid of (default) dynamic scoping, but in macros
> this is still the default.

  Really?

> If your macro references a variable X, it just grabs whatever X happens
> to be available at the location where the macro is used.

  This is not what we call dynamic scope.

> Like dynamic scoping for lambdas, people who have gotten used to that
> tend to like it, and indeed can proffer a whole battery of situations
> where this 'feature' can be exploited -- again the guru phenomenon.

  When will it occur to you that _you_ are actually inventing the gurus?

> Normally you mean 'this variable' but have to write 'X', again not quite
> the same thing.  As with functions, lexical scoping (referential
> transparency) should be the default, with an option for dynamic scoping.

  That _is_ the situation today.

  FYI: people have written macros that hide the mechanics of "fresh
  variables".  Those should arguably have been part of the language, but
  they are not, for whatever reason.  So it is part of the oral tradition.
  Big deal.  Learning to do anything well requires effort.  If instead of
  learning you rebel against the effort, you will never do it well, and
  that itself will be an argument in favor of not doing it the way it
  should be done.

  I submit that the way you have treated macros in Common Lisp is exactly
  the same way that turn people into criminals.  Rather than understanding
  the existing set of rules and living within them, they break them out of
  sheer ignorance and arrogance, then the rules hit them back, because they
  are not quite as arbitrary as the whim of those who break them, and they
  get _another_ reason to break the rules: The rules are bad and they hurt
  you.  If you want to break the rules, first you must understand them and
  then break them by achieving what they were intended to achieve better
  than the rules already achieve, such as by eliminating a negative side
  effect.  Otherwise, there is no constructive element in breaking the
  rules, only destructiveness, and that is never appreciated, except
  possibly by others of the same rebel inclination.

> (3) So since the macro writer wants to state "whenever I say this I MEAN
> that", but the system wants to hear "whenever you say this, I should
> assume that you SAID that", macro writing necessarily involves fighting
> the system.

  What if you got it all wrong?  What if _you_ are fighting "the system"
  only because you have misuderstood what "the system" is doing and how it
  works?

> It is a lot like legalese: a lawyer is also a guru in bringing a meaning
> across in a system that tends to look at texts, but it involves
> non-trivial phrasings, and often a lot more text than one might have
> thought.  If a non-guru draws up a legal document, it is likely there are
> loopholes.

  And the problem here is what?

> Does that help?  Again, if you are familiar with the system, the
> "macrolese" may come naturally, and even appear obvious, and definitely
> prove exploitable in ways that a "correct" solution would not be -- again
> the comparison with lawyers comes to mind :-)

  An analogy to a skilled craftsman versus an unskilled craftsman comes to
  _my_ mind.  Maybe that is because I happen to think that the idiotic
  attitude problem many people have towards lawyers is based in exactly the
  same willful and arrogant ignorance of "the system" that those who hate
  macros or Lisp in general suffer from.

  This is only a problem with _your_ approach to macros, "Biep @
  http://www.biep.org/".  If you could bother to study how it works and try
  to learn to use it properly, you would probably be able to find a way to
  express what you need, just the way you want to express it.  You see, the
  whole idea with macros is expressibility.

  Simply put: If you do not want to learn the language, do not blame the
  language for your inability to express yourself in it.

#:Erik
-- 
  Travel is a meat thing.
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fo442$53sri$1@ID-63952.news.dfncis.de>
Erik, would you please go away?  If you had bothered to try to read what I
wrote, you would have understood that I don't have the least problem expressing
what I want to express using the CL macro system, and that I do not propose that
anything should change.  This is the second time you, out of nothing, start
spouting stuff at me that has nothing to do with what I am writing about and is
at the same time offensive.

--
Biep
Reply via http://www.biep.org
From: Wade Humeniuk
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fo4u3$mon$1@news3.cadvision.com>
Quit being a troll.

Or in CL

(defvar biep (open "ears" :direction :input))
(write "Quit Being A Troll!" :stream biep)
(flush-output biep)
(close biep)

Or with a CL macro

(with-open-file (biep "ears" :direction :input)
    (write "Quit Being A Troll!" :stream biep)
    (flush-output biep))

Wade

"Biep @ http://www.biep.org/" <·········@my-web-site.com> wrote in message
···················@ID-63952.news.dfncis.de...
> Erik, would you please go away?  If you had bothered to try to read what I
> wrote, you would have understood that I don't have the least problem
expressing
> what I want to express using the CL macro system, and that I do not
propose that
> anything should change.  This is the second time you, out of nothing,
start
> spouting stuff at me that has nothing to do with what I am writing about
and is
> at the same time offensive.
>
> --
> Biep
> Reply via http://www.biep.org
>
>
From: Jochen Schmidt
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fohim$566pj$1@ID-22205.news.dfncis.de>
Wade Humeniuk wrote:

> Quit being a troll.
> 
> Or in CL
> 
> (defvar biep (open "ears" :direction :input))
> (write "Quit Being A Troll!" :stream biep)
> (flush-output biep)
> (close biep)
> 
> Or with a CL macro
> 
> (with-open-file (biep "ears" :direction :input)
>     (write "Quit Being A Troll!" :stream biep)
>     (flush-output biep))

Nice said ;-)
But Biep will hear more if we use :output as :direction.
The standpoint taken in CLs notion of "direction" is the Lisp System not
the file. So "input" means "The Lisp System gets input from a file"
and "output" means "The Lisp System outputs to a file"

Regards,
Jochen
From: Wade Humeniuk
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fonl2$u65$1@news3.cadvision.com>
I made a mistake :), let me correct,

In the first case

(close biep) ; since it was not cleaned up
(setf biep (open "ears" :direction :output))
(write "Quit Being A Troll!" :stream biep)
(flush-output biep)
(close biep)

Or with the macro

(with-open-file (biep "ears" :direction :output)
    (write "Quit Being A Troll!" :stream biep)
    (flush-output biep))

But I think I really should have created a new macro like

(with-persons-aural-attention (biep :uri "http://www.biep.org")
    (tell biep "Quit Being A Troll!"))

or

(biep! Quit Being A Troll!)

or

(biep!!!!!!!)

After all thats what macros are for.

Wade


"Jochen Schmidt" <···@dataheaven.de> wrote in message
···················@ID-22205.news.dfncis.de...
> Wade Humeniuk wrote:
>
> > Quit being a troll.
> >
> > Or in CL
> >
> > (defvar biep (open "ears" :direction :input))
> > (write "Quit Being A Troll!" :stream biep)
> > (flush-output biep)
> > (close biep)
> >
> > Or with a CL macro
> >
> > (with-open-file (biep "ears" :direction :input)
> >     (write "Quit Being A Troll!" :stream biep)
> >     (flush-output biep))
>
> Nice said ;-)
> But Biep will hear more if we use :output as :direction.
> The standpoint taken in CLs notion of "direction" is the Lisp System not
> the file. So "input" means "The Lisp System gets input from a file"
> and "output" means "The Lisp System outputs to a file"
>
> Regards,
> Jochen
>
From: Coby Beck
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <s2sU6.424815$o9.67361839@typhoon.tampabay.rr.com>
childish crap.

Coby


"Wade Humeniuk" <········@cadvision.com> wrote in message
·················@news3.cadvision.com...
> I made a mistake :), let me correct,
>
> In the first case
>
> (close biep) ; since it was not cleaned up
> (setf biep (open "ears" :direction :output))
> (write "Quit Being A Troll!" :stream biep)
> (flush-output biep)
> (close biep)
>
> Or with the macro
>
> (with-open-file (biep "ears" :direction :output)
>     (write "Quit Being A Troll!" :stream biep)
>     (flush-output biep))
>
> But I think I really should have created a new macro like
>
> (with-persons-aural-attention (biep :uri "http://www.biep.org")
>     (tell biep "Quit Being A Troll!"))
>
> or
>
> (biep! Quit Being A Troll!)
>
> or
>
> (biep!!!!!!!)
>
> After all thats what macros are for.
>
> Wade
>
>
> "Jochen Schmidt" <···@dataheaven.de> wrote in message
> ···················@ID-22205.news.dfncis.de...
> > Wade Humeniuk wrote:
> >
> > > Quit being a troll.
> > >
> > > Or in CL
> > >
> > > (defvar biep (open "ears" :direction :input))
> > > (write "Quit Being A Troll!" :stream biep)
> > > (flush-output biep)
> > > (close biep)
> > >
> > > Or with a CL macro
> > >
> > > (with-open-file (biep "ears" :direction :input)
> > >     (write "Quit Being A Troll!" :stream biep)
> > >     (flush-output biep))
> >
> > Nice said ;-)
> > But Biep will hear more if we use :output as :direction.
> > The standpoint taken in CLs notion of "direction" is the Lisp System not
> > the file. So "input" means "The Lisp System gets input from a file"
> > and "output" means "The Lisp System outputs to a file"
> >
> > Regards,
> > Jochen
> >
>
>
>
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fq2jf$5g0ek$1@ID-63952.news.dfncis.de>
:-)

But actually, I am not trolling - This started as a simple explanation why some
code was more complex than average, and then Erik jumped in misreading my
comments.

--
Biep
Reply via http://www.biep.org

"Wade Humeniuk" <········@cadvision.com> wrote in message
·················@news3.cadvision.com...
> Quit being a troll.
>
> Or in CL
>
> (defvar biep (open "ears" :direction :input))
> (write "Quit Being A Troll!" :stream biep)
> (flush-output biep)
> (close biep)
>
> Or with a CL macro
>
> (with-open-file (biep "ears" :direction :input)
>     (write "Quit Being A Troll!" :stream biep)
>     (flush-output biep))
>
> Wade
>
> "Biep @ http://www.biep.org/" <·········@my-web-site.com> wrote in message
> ···················@ID-63952.news.dfncis.de...
> > Erik, would you please go away?  If you had bothered to try to read what I
> > wrote, you would have understood that I don't have the least problem
> expressing
> > what I want to express using the CL macro system, and that I do not
> propose that
> > anything should change.  This is the second time you, out of nothing,
> start
> > spouting stuff at me that has nothing to do with what I am writing about
> and is
> > at the same time offensive.
> >
> > --
> > Biep
> > Reply via http://www.biep.org
> >
> >
>
>
From: Coby Beck
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <J0sU6.424799$o9.67359583@typhoon.tampabay.rr.com>
"Wade Humeniuk" <········@cadvision.com> wrote in message
·················@news3.cadvision.com...
> Quit being a troll.
>

I have not read the thread past this point, but so far completely disagree
that this person is trolling.

I find the discussion interesting and educating.  Erik Naggum wrote recently
in another thread (the "aref inline?" one) very correctly about how in the
usenet forum, it "pays off to be imprecise and incorrect in order to produce
the most lucid  answers."  So I think there is much more to be gained in
this discussion by getting the chips off the shoulder keeping the discussion
technical.  Biep has committed no outrage at this point.

Coby

Addendum:  My familiarity and skill with macros is such that I can write
them and use them to solve interesting and complex problems in ways that I
find very satisfying but still do not yet fully understand much of what I
see being discussed at times.  I like them very much but do not fear hearing
what others dislike, nor hearing criticisms I already disagree with, it
helps me learn.
From: Wade Humeniuk
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fua6j$sjo$1@news3.cadvision.com>
"Coby Beck" <·····@mercury.bc.ca> wrote in message
·····························@typhoon.tampabay.rr.com...
>
> "Wade Humeniuk" <········@cadvision.com> wrote in message
> ·················@news3.cadvision.com...
> > Quit being a troll.
> >
>
> I have not read the thread past this point, but so far completely disagree
> that this person is trolling.
>
> I find the discussion interesting and educating.  Erik Naggum wrote
recently

You like it that Biep is starting to insult Erik and in an attempt to get
him going?

He bashes the current macro system without having no replacement.  Then he
says he is not bashing the current system.  Then insists that Scheme might
be on the road onto a better one. Then he starts insulting Eirk's
intelligence.  Provoking Erik, for me, says that he is a scheming troll.
Biep knows better.

Wade
From: f_o_o_
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <1fce7ff3.0106100246.60029962@posting.google.com>
"Wade Humeniuk" <········@cadvision.com> wrote in message news:<············@news3.cadvision.com>...
> You like it that Biep is starting to insult Erik and in an attempt to get
> him going?
What a pile of crap! 
In <················@naggum.net> it was E that was provoking - 
strange, having such an uncalled for attack with all that fuss over 
the "fighting the system" phrase, just because E had previous judgement 
over B - when he accuses most people of doing this to him.

> He bashes the current macro system without having no replacement.  Then he
He bashed nothing - he had it in a comment, in double quotes and later admitted 
he doesn't know macros too well.  

> says he is not bashing the current system.  Then insists that Scheme might
> be on the road onto a better one.
E was the one who brought hygienic macros into the thread.

> Then he starts insulting Eirk's
> intelligence. 
How? Look at that post - E just came out of nowhere in a clear attack because 
of some personal past issues with B, and in what seemed to be an attempt 
to AVOID a fight, B did not reply for his posts. Anyway, insulting E's 
intelligence seems to be a very easy thing to do. 

> Provoking Erik, for me, says that he is a scheming troll.
Oh god...if you just pull your tongue out of E's ass for a couple of minutes 
you might think better. It's so fucking annoying to see people happily 
shove their tongues up there just because he seem to know more than 
you do. Like that magic flute he uses his infinite cheap speeches 
and bad cliches to drag you morons behind him. The damage he 
does for Lisp is far beyond his technical "contributions" 
only if for this killing of anyone that dares saying 
something bad on CL - other people are open to hearing 
about good things from others while E is so focused around 
he's speeches about smart people not locking on  a single way of thinking 
that he is completely unaware of anything and anyone except for himself. 
Just Get a Fucking Life. 

> Biep knows better.
> 
> Wade
From: Wade Humeniuk
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fvv1e$h95$1@news3.cadvision.com>
Like your comments are helping.  Quit being a troll.

Wade
From: f_o_o_
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <1fce7ff3.0106101510.24ac3c0a@posting.google.com>
"Wade Humeniuk" <········@cadvision.com> wrote in message news:<············@news3.cadvision.com>...
> Like your comments are helping.  Quit being a troll.
Yeah, unlike your comments that were so full of useful info. 
Now go wash your mouth now.
From: Wade Humeniuk
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9g18gf$v6v$1@news3.cadvision.com>
"f_o_o_" <······@hushmail.com> wrote in message
·································@posting.google.com...
> "Wade Humeniuk" <········@cadvision.com> wrote in message
news:<············@news3.cadvision.com>...
> > Like your comments are helping.  Quit being a troll.
> Yeah, unlike your comments that were so full of useful info.
> Now go wash your mouth now.

OK, I will comment.

When it comes to programming I think Common Lisp is the best language
around.  Go to a Java or C++ group and they will not tear down the language
they think is great.  But we have people coming on the group espousing that
they like CL and then proceeding to point out their perceived weakness of
the language.  They troll with obvious errors in their perception, they
think that they are somehow smarter than the programmers that went before
and developed the language from _experience_.  The developers of CL in my
opinion were geniuses and deserve more respect.  It is hard enough to use CL
without all the destructiveness, doubt and chaos written by CL "supporters".
Push the language to its limits and if you find a deficiency, then you can
discuss whether it should be changed.

Why is this?  I think programmers may come to use CL because of how
disenchanted they are with programming in general (that is how it was for
me).  Any imperfection further magnifies their disenchantment and the blame
of those that went before starts.  CL is the best game going but it is still
a programming language and does not do the thinking and work for you.  If
somehow we had a magic/perfect macro system it would not change that one
iota.  This is as good as it gets.

Wade
From: Erik Naggum
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <3201241707519342@naggum.net>
* "Wade Humeniuk" <········@cadvision.com>
> Why is this?  I think programmers may come to use CL because of how
> disenchanted they are with programming in general (that is how it was for
> me).  Any imperfection further magnifies their disenchantment and the
> blame of those that went before starts.

  This is insightful.  Starting to use Common Lisp for real felt like
  arriving in what some call heaven, nirvana, etc.  Then I found that there
  were a lot of stuff that I needed to do at a lower level.  I always liked
  the lower levels, but I always hated having to do stuff there that did
  not belong there, such as the repetitiveness of command line processing
  in Unix and C's "main", which no two programs do exactly the same way.

  The other day, I found _another_ "idiot bug" in the Common Lisp printer.
  (write #*101 :radix t :base 36) produces #*#36r1#36r0#36r1 in Allegro CL
  and CMUCL.  When I read Wade's comment now, I realized that my sense of
  _betrayal_ in discovering that bug and my subsequent exasperation with
  having to track it down and fix it, knowing (and fearing) that hundreds
  of similar printer-control-variable-unaware bugs floats around, was such
  a downer precisely because my expectations are so much higher to begin
  with, but also that somebody else's sense of quality had not produced
  code that was free of this particular "thinko".  It may be like finding a
  dirty fork in a fine restaurant -- somebody did not care as much as one
  had reason to expect.

  This may also explain why some people are so reluctant to use Common Lisp
  functionality that is not part of the language -- because so much of what
  we need is already part of the language.  So Common Lisp gets blamed for
  not being perfect.  The other side of this is that some people are afraid
  to use Common Lisp because they think their code needs to be beautiful
  all the time.  Some people get disappointed when they discover that what
  makes a Common Lisp system is a lot of "dirty" code, interfacing with
  "dirty" operating systems and their "dirty" tricks.  Manufacturing the
  most beautiful things is not at all a beautiful process.  Anyone who has
  ever visited the manufacturing plant for stuff that looks very elegant
  when they are new at the end-user site realizes that the process and the
  result may have radically different characteristics.  Perhaps the strong
  sense of disappointment betrays a lack of understanding of this
  difference and the irrational desire to see manufacturing as elegant as
  the results.  This also applies to code for functions that export some
  beautiful interface, but are quite messy inside because of all the gory
  details they hide from the user of that interface.

  Perhaps there is a psychology of beautiful things that make us fear they
  might break or prove insufficient at close inspection.  If so, it needs
  to get fixed.  How can we do that?

#:Erik
-- 
  Travel is a meat thing.
From: Wade Humeniuk
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9g31l5$huf$1@news3.cadvision.com>
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
>
>   Perhaps there is a psychology of beautiful things that make us fear they
>   might break or prove insufficient at close inspection.  If so, it needs
>   to get fixed.  How can we do that?

I started to write a whole bunch of stuff but I have decided to keep it
simple.

We hold to the objects of our perception trying to prolong our pleasure.
The more beauty the harder we hang on.  Let go.  You cannot move ahead if
you hang on.

And of course a list:

1) Laugh about it.  It really is quite funny.
2) Write code even if it is messy.  Write it in the most natural and organic
way for you.  Take advantage of the Lisp way of writing code.
3) Keep your code as much as you can within the Lisp paradigm and only at
the last moment translate its internal structure to use external libraries
and operating systems.
4) Keep it direct and simple.
5) Keep the big picture in mind.
6) When in doubt type some more.
7) Beauty is in the eye of the beholder.
8) When it looks ugly, remember that you did it, not Lisp.

Wade
From: Erik Naggum
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <3201177967847260@naggum.net>
* ······@hushmail.com (f_o_o_)
> In <················@naggum.net> it was E that was provoking - 
> strange, having such an uncalled for attack with all that fuss over 
> the "fighting the system" phrase, just because E had previous judgement 
> over B - when he accuses most people of doing this to him.

  Dear Anonymous Idiot,

  You do not know that I had any previous "judgment over "Biap"".  This is
  something you invent out of your very own hostility towards me, and it
  shows that you are indeed the prototypical anonymous idiot on theh Net.

  Anybody who hides behind a useless identification of the person has shown
  the world that he thinks the world would treat him harsher if they knew
  who he was.  We have to trust that judgment and keep anonymous idiots to
  much higher standards than people who identify themselves and show the
  world that they accept personal responsibility for their mistakes and
  erros.  An anonymous idiot can become _another_ anonymous idiot when he
  has run out of goodwill.  This is why idiots prefer to be anonymous.

  Therefore, there is no previous judgment, there is a _requirement_ of a
  person who posts anonymously _not_ to be an idiot.  Any shred of idiocy
  from an anonymous poster is prima facie evidence of destructiveness, the
  criminal mind, trolling, what have you.  Otherwise, the anonymous poster
  would have been a _responsible_ person.

  Any one of us might want to be anonymous in some circumstance or another,
  but then we realize that we start of with negative goodwill.  People will
  wonder why we need to be anonymous.  It may not be perceived to be anyone
  else's business by the anonymous poster, but it _is_ a valid question.
  If an anonymous poster turns out to be disrespectful, everobyd _knows_
  the reason they need to be anonymous: They are destructive bastards who
  are trying to get away with it by being anonymous.

  Being anonymous has its costs.  Some of those who want to be anonymous
  are _exactly_ the "rebel nature" that defy rules just to defy them.
  There is no _point_ to their rebellion other than that they do not like
  that other people set the rules.  _They_ want to set the rules.  And what
  do you kno?  "Biap" has shown us that he wants to set the rules, too.
  What a huge surprise that is to those who think through things in general.

> Oh god...if you just pull your tongue out of E's ass for a couple of
> minutes you might think better.

  This, for instance, is why you need to be anonymous.  And now is a good
  time for you to change your anonymous identification to something else.

> The damage he does for Lisp is far beyond his technical "contributions"

  Then again, maybe you are a little less anonymous than one might think.
  The people who have produces similar diarrhea here have not found an
  audience worth having, so there is no wonder you hide behind a stupid
  anonymous identification.

> only if for this killing of anyone that dares saying something bad on CL

  This is the ususl problem with you morons.  You think that disagreement
  is the issue.  You think that it is the insanely retarded attitude _you_
  have towards things in general that also motivates other people.  It is
  not.  I may have to repeat that: Other people do not have the retarded
  reasons for their arguments that you would have had if you had tried to
  argue similarly.  People who have a serious understanding of any issue
  can say whatever they want, bad, good, neutral, and people listen to them
  because those who listen can destill useful information to their own
  needs.  _Everybody_ has a form of communication that is disagreeable to
  some people if they have anything worth saying at all.  If everybody
  agrees with you, you are only being nice without saying anything at all.
  This is the favorite mode of communication among idiots.  Just watch
  them.  Extremely contentless polite exchanges of meaningless sounds that
  are forgotten before the sound waves have vanished.  Meaningful discourse
  among intelligent people _necessarily_ means that somebody favorite idea
  gets trashed.  The measure of an intelligent response is that it puts its
  personal prestige behind having good ideas, not that whatever ideas it
  had have to be good.  Some people, mostly those married to their ideas,
  cannot tolerate that they turn out to be wrong, and fight those who make
  that obvious.

  It is important to notice whether people defend what they have or seek to
  adopt what they find.  Those who defend _themselves_ because they confuse
  themselves with what they have, are useless in any discussion.  They need
  to be identified and weeded out.  If you want to take part in a useful
  discussion, you should expect to learn something and leave richer than
  when you entered.  If you defend and keep an idea that turns out to be
  bad, you leave poorer than when you entered.  Do not defend yourself.  Do
  not defend your idea.  Defend how you came to conclude what you did, so
  that others can examine and criticize that.  Everybody makes mistakes in
  identifying what they observe, but if they cannot distinguish between
  what they observe and what they conclude it was they observed, then there
  is no hope at all of correcting their mistakes, because they cannot make
  _another_ conclusion from the same observation.  People who are _unable_
  to do that should just be kept out of public fora, or forced to get out
  if they refuse to take a few hundred hints.

> - other people are open to hearing about good things from others while E
> is so focused around he's speeches about smart people not locking on a
> single way of thinking that he is completely unaware of anything and
> anyone except for himself.

  Next time you feel the urge to post your incredibly intelligent thoughts
  on someone's thinking process, try someone you know.  Perhaps yourself,
  but I do get the impression that you know yourself even less than me.

> Just Get a Fucking Life. 

  I must assume you have followed that advice yourself, but it is rather
  tragic what you made out of it.  Are you sure you are in a position to
  give this advice to others at all?

  You are of course welcome to continue to post your diarrhetic wastes here
  if this is what your understanding of "a Fucking Life" requires you to
  do, but you should realize that other people have other goals and means
  than you do.  For instance, you should use your computer to play games
  that require motor skills instead of intelligence games like USENET.

  If you _should_ want to try to post again, just get a fucking _name_.

#:Erik
-- 
  Travel is a meat thing.
From: f_o_o_
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <1fce7ff3.0106101600.2f314657@posting.google.com>
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
>   Dear Anonymous Idiot,
Where theh hell did you come from? I was not talking to you. 
> 
>   You do not know that I had any previous "judgment over "Biap"".  
So what was "It has been obvious for quite a while that you are here
only to talk, not to listen, not to learn, not to appreciate contrary
opinions and views."
>   erros.  An anonymous idiot can become _another_ anonymous idiot when he
>   has run out of goodwill.  
No good will, mot even negative good will, just wish you take your
ususl crap and disappear.
> 
>   This is the ususl problem with you morons.  You think that disagreement
>   is the issue.  
No, the issue is you.

>   argue similarly.  People who have a serious understanding of any issue
>   can say whatever they want, bad, good, neutral, and people listen to them
>   because those who listen can destill useful information to their own
>   needs.  
Oh and youre one of these people with serious understanding... 
The fact is that there are plenty of stupid people who have lots of
people that
listen to them - it is called politics, not surprising considering
your cheap
loong pointless speeches. You are an infectious disease, like many of
these
politicians.
> 
>   _another_ conclusion from the same observation.  People who are _unable_
>   to do that should just be kept out of public fora, or forced to get out
>   if they refuse to take a few hundred hints.
I think that now you have more than a few hundred hints. Take it and
shutup.
> 
>   If you _should_ want to try to post again, just get a fucking _name_.
> 
> #:Erik

#:name
From: Erik Naggum
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <3201240042126140@naggum.net>
* ······@hushmail.com (f_o_o_)
> Where theh hell did you come from? I was not talking to you. 

  For your infornation, dear anonymous idiot, this is a public forum.  This
  means that you do not talk to individual people.  You offer your opinions
  to the public forum and others are free to offer theirs.  This is not the
  highly personal exchange that you think it is.  Such is called "mail", or
  maybe you are more familiar with the name "private chat room", judging by
  your behavior.  I, too, dislike the concerned bystander, but you are in
  fact talking about me, so I fail to see how I am not talked to.  Perhaps
  you are the kind of person who believes that he can slander people
  publicly in what he thinks is private conversation because he does not
  understand that he is shouting in a public place?  You strike me as about
  smart enough to believe such things.

> >   You do not know that I had any previous "judgment over "Biap"".  
> So what was "It has been obvious for quite a while that you are here
> only to talk, not to listen, not to learn, not to appreciate contrary
> opinions and views."

  A statement of fact, that did not influence my judgment of him this time,
  but added the judgment this time to previous judgments.  The causal link
  that you invented in your hostility towards me does not exist.  You see,
  it _is_ possible for other people than yourself to behave rationally and
  not let their previous judgments color what they observe, but still
  _remember_ the past, when and as it becomes relevant.  That you refuse to
  believe this says a whole lot about you that I am luckily relieved of
  putting into explicit terms.

> No good will, mot even negative good will, just wish you take your ususl
> crap and disappear.

  Are you doing a good job in encouraging less crap on this newsgroup?  Are
  you able to observe the fact that until you started posting the crap for
  which you are the _only_ responsible party, there was much less of it?

> No, the issue is you.

  Insight!  This is progress.  To _you_, _I_ am the issue.  This is _your_
  problem, however.  The topic of this newsgroup is _not_ "people that
  anonymous idiots like to attack".  This is public forum, not your living
  room, and you have _no_ power to dictate anything.  Learn to deal with
  it.  If you are only here to complain and whine, you are the root cause
  of the problems you do not like.  Be constructive.  Do what you think
  this newsgroup should be used to do.  It _is_ that simple.  Trolls and
  whining losers like yourself only produce hostility and resentment.

> The fact is that there are plenty of stupid people who have lots of
> people that
> listen to them - it is called politics, not surprising considering
> your cheap
> loong pointless speeches.  You are an infectious disease, like many of
> these
> politicians.

  It looks to me like you are engaged in politics and bad line-breaking.

  Considering that you have absolutely _no_ power to make me do anything,
  and that it looks like you are desperately trying to change that even
  though it is completely futile, have you at all considered that the way
  you go about whatever it is you want, produces the _oppsite_ results, at
  least as far as your incessant whining reaction can tell?

  The only course of action is never, ever to reply to people who refuse to
  identify themselves properly.  This, however, is a prejudgment on people
  who may have reason to hide their identity.  The way to deal with this is
  by using a pseudonym or an alias that at least looks like a real name.
  Since the anonymous idiots cannot even figure _that_ out on their own,
  and we have no idea who are actually behind moet names, anyway, it is
  probably no point in grieving over those who do not sign their posts with
  real names but who _might_ be something other than rabid dogs.  Let us
  safely assume that if you are anonymous, you are an idiot, and not only
  that, you are an idiot out to make trouble.

#:Erik
-- 
  Travel is a meat thing.
From: Marc Spitzer
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <slrn9i5lap.2157.marc@oscar.eng.cv.net>
In article <············@news3.cadvision.com>, Wade Humeniuk wrote:
> 
> "Coby Beck" <·····@mercury.bc.ca> wrote in message
> ·····························@typhoon.tampabay.rr.com...
>>
>> "Wade Humeniuk" <········@cadvision.com> wrote in message
>> ·················@news3.cadvision.com...
>> > Quit being a troll.
>> >
>>
>> I have not read the thread past this point, but so far completely disagree
>> that this person is trolling.
>>
>> I find the discussion interesting and educating.  Erik Naggum wrote
> recently
> 
> You like it that Biep is starting to insult Erik and in an attempt to get
> him going?
> 
> He bashes the current macro system without having no replacement.  Then he
> says he is not bashing the current system.  Then insists that Scheme might
> be on the road onto a better one. Then he starts insulting Eirk's
> intelligence.  Provoking Erik, for me, says that he is a scheming troll.
> Biep knows better.
> 
> Wade

From what I have read of Erik's posts here, insulting his intelligence is 
stupid.  If you read what he writes there is no way a person of average
or better inteligence could think he is less then very smart and educated.
You may not agree with it but he presents a very good argument.

marc

> 
> 
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9gku8b$9cu8f$1@ID-63952.news.dfncis.de>
"Wade Humeniuk" <········@cadvision.com> wrote in message
·················@news3.cadvision.com...
> You like it that Biep is starting to insult Erik
> and in an attempt to get him going?

On the contrary.  I made a mistake in replying to him (and probably now in
replying about him).  I spent a tedious discussion trying to find out how he
associates meanings with words and expressions, and besides long off-topic
ramblings all I got was ricochet name calling (Instead of saying "you are
retarded", saying "anybody who does that is retarded"  when he thinks I do
that).

In comp.org.lisp-users someone asked about Lisp versions, and (in line with the
FAQ of the ALU, whose group it is as far as I know), I mentioned CL and Scheme.
Erik took me to task for mentioning Scheme (for some reason this article has
dropped out of the thread on Google).  Here is the ensuing conversation:
http://groups.google.com/groups?hl=nl&lr=&newwindow=1&safe=off&ic=1&th=2b9d6cbc1
34014a8,35.

While he made it abundantly clear that he does not consider Scheme a Lisp (in
the given context), I still don't know what grounds he uses in determining what
I (or the ALU, or the person asking the original question) should mean when
saying "a Lisp".

So I decided to ignore him - I love debating issues, but debating with someone
who can only deal with the person, and gets nervous when he doesn't know WHO it
was who said something simply doesn't interest me.

Kill files are a useful feature after all :-)

--
Biep
Reply via http://www.biep.org
From: Erik Naggum
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <3201861082708218@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> So I decided to ignore him - I love debating issues, but debating with someone
> who can only deal with the person, and gets nervous when he doesn't know WHO it
> was who said something simply doesn't interest me.

  For your information, you have spent the vast majority of your time
  complaining about me, and not discussing anything.  You have only posted
  your rationalizations of why you cannot manage to debate any issues when
  the other party identifies something you do wrong and refuse to discuss
  with such morons as yourself.  I find this rather amusing.

  The fact that you resort to kill-files is _another_ piece of evidence
  that you have a problem with _people_.  I find this rather amusing, too.

  The fact is that you cannot deal with the issues unless _you_ are dealt
  with very nicely first, no matter how silly things you say.  If you are
  not happy about the people you discuss with, you _only_ complain about
  them, never about anything they said, and you always run away from any
  and all criticism of your arguments if you can dislike the person.  I
  find this amazingly retarded behavior.  The fact that you do not post
  with your full name is probably a _very_ good idea on your part.

#:Erik
-- 
  Travel is a meat thing.
From: Duane Rettig
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <4k82o5kfg.fsf@beta.franz.com>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> Erik, would you please go away??

Don't want to deal with it, eh?

> If you had bothered to try to read what I
> wrote, you would have understood that I don't have the least problem
> expressing what I want to express ...

Then again, maybe you do want to deal with it...

When people express themselves, there are two possible motivations for
doing so.  One is emotion - when people emote, they don't care about
others hearing what they have to say, but the goal is in the expression
itself.  For example, artists must be able to express themselves freely
without necessarily having to communicate.  Complainers also express
themselves without communicating.

The second aspect of expression _is_ communication.  Communication has
both a sender and a receiver of information.  Those who express themselves
well in this sense have a good idea as to how their listeners are receiving
what they have to say.

Now, the first part of the second sentence above tells me that you don't
want to just spout off, but that you want people to understand what you say.
However, I contend that you are not necessarily doing that well.  And the
fault may be ours completely, because of our point-of-view, but let's take
an example of how you should try to listen to yourself from my point of
view if you want me to understand you:

You give your web address as http://www.biep.org/.  However, when I
tried to get to your website in my netscape, I got an error:
"This Virtual Directory does not allow contents to be listed."
Now, I don't know what the problem is, here; it may be a problem
entirely on my end.  However, I never have any trouble getting anywhere
else on the web, and so your site is particular in at least one
sense.  Perhaps your site is just busy, or perhaps you have never tested
it using Netscape on a unix box.  However, this just illustrates the
points Erik and Marco were trying to make:

If we disagree on the usage of macro writing, perhaps it is because
there is a disconnect between what you are saying and what we are hearing.
Many of the things that Erik specifically mentioned communicated to me
that he had indeed read and understood what you were saying, and if these
understandings were not what you were trying to say, then you must
find a way to close the communication gap if you want people to
understand you.

I suggest that you go back over Erik's post and respond point-by-point,
correcting any mistaken assumptions that he might have made.  Bear in mind,
that I had the same assumptions that he did, and would have responded
to at least a couple of your points in similar manner.  For example,
the fact that the CL community does not care to continue developing
their macro system and the scheme community does, suggests to me that
the scheme community is dissatisfied with their macro system, whereas
the CL community is satisfied with theirs.

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwk82o6stl.fsf@world.std.com>
Duane Rettig <·····@franz.com> writes:

> [context elided. see prior posts if that matters to you.]
>
> For example, the fact that the CL community does not care to
> continue developing their macro system and the scheme community
> does, suggests to me that the scheme community is dissatisfied with
> their macro system, whereas the CL community is satisfied with
> theirs.

I think this is a good point.

I think the Scheme community is puzzled by the fact that CL doesn't
have a hygienic macro system and yet doesn't run into all kinds of
problems as a result.  Usually this kind of "surprise" comes from
momentarily making the mistake of assuming that the conversation can
usefully proceed by idealizing the differences between the two
languages as being "only this" and assuming that what keeps the
conversation focused will not leave out critical information that
makes the conversation meaningful.  It is impossible to have a
conversation about macros without a conversation on namespaces and
packages (and "hygiene" is as much about those other two issues as it
is about macros).  Yet they mostly forget to bring them into play when
looking at our macro system.  We in CL rely on the Lisp2ness and on
the package system to protect us from name conflicts, and in practice,
it does.  To my knowledge, having worked at several Lisp vendors and
having used CL now about 2 decades years, people who know what they
are doing reliably do not run into any problems with name collisions
in CL.  The problem just doesn't come up.  The ecology works.

I guess my point is that Duane is not just speculating when he says
"suggests to me that...".  There's pretty extensive experience with
myriad users and multiple implementors over a really long time (in 
"contemporary programming language use" terms) to suggest that the
reason no one is "evolving" the CL macro system is that it works just
fine.

In fact, historically, the biggest boom in Lisp productivity and expansion
that I've ever seen occur was around the time that people discovered the
creation and exchange of "cool macros".  Lots of macro packages were offered
by the system and by users, and, by all accounts, productivity AND program
reliability went way up because tedious idiomatic uses didn't have to be
painstakingly repeated any more, at risk that people would find the longhand
versions too painful to do in full form or that they would make a mistake
in adjusting them for context.  Macros changed the Lisp world, very much
for the better.  And since that time, I've heard no regrets and no "gee,
this is getting out of hand".  Rather, I've heard people continuing to
be amazed by how many layers you can create of macro on macro and still get
utterly reliable outcomes.
From: Rob Warnock
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fpk2t$evaa6$1@fido.engr.sgi.com>
Kent M Pitman  <······@world.std.com> wrote:
+---------------
| Duane Rettig <·····@franz.com> writes:
| > For example, the fact that the CL community does not care to
| > continue developing their macro system and the scheme community
| > does, suggests to me that the scheme community is dissatisfied with
| > their macro system, whereas the CL community is satisfied with theirs.
| 
| I think this is a good point.
| 
| I think the Scheme community is puzzled by the fact that CL doesn't
| have a hygienic macro system and yet doesn't run into all kinds of
| problems as a result.
+---------------

Confession: I happen to program in both CL & Scheme and, as it happens,
when I write macros in Scheme I always use "defmacro", since it does the
(to me) obvious & correct thing. [Hygiene? See "gensym".]

+---------------
| There's pretty extensive experience with myriad users and multiple
| implementors over a really long time (in "contemporary programming
| language use" terms) to suggest that the reason no one is "evolving"
| the CL macro system is that it works just fine.
+---------------

That's why I've never bothered to learn R5RS macros, even though they're
"standard" and defmacro isn't. The latter is all I need; I understand what
it does; and all of the implementations of Scheme I use (and of course,
all of the CLs) have it (or something equivalent from which it can be
trivially defined).


-Rob

p.s. It may help that I use to code some *incredibly* complex things
in MACRO-10 (the PDP-10 assembly language) macros way back when...  ;-}
It didn't have "gensym" per se -- you had to manually construct your
own unique macro temp symbols by concatenating assembly-time counters
and local prefixes & suffixes & the like. But now that I think about it,
one could have easily written "gensym" *in* MACRO-10 macros! (I just never
would have called it that, since I hadn't been exposed to Lisp yet.)

-----
Rob Warnock, 31-2-510		<····@sgi.com>
SGI Network Engineering		<http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA

[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]  
From: Christopher Stacy
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <ug0dbjs6o.fsf@spacy.Boston.MA.US>
>>>>> On 8 Jun 2001 04:25:01 GMT, Rob Warnock ("Rob") writes:
 Rob> p.s. It may help that I use to code some *incredibly* complex things
 Rob> in MACRO-10 (the PDP-10 assembly language) macros way back when...  ;-}
 Rob> It didn't have "gensym" per se -- you had to manually construct your
 Rob> own unique macro temp symbols by concatenating assembly-time counters
 Rob> and local prefixes & suffixes & the like. But now that I think about it,
 Rob> one could have easily written "gensym" *in* MACRO-10 macros! (I just never
 Rob> would have called it that, since I hadn't been exposed to Lisp yet.)

The PDP-10 systems at MIT were programmed using the MIDAS assembler,
which was even more powerful than MACRO-10.  To wit,

   GENSYMMED DUMMIES.

   If a gensymmed dummy is unspecified,
   its value will be a GENERATED SYMBOL
   6 characters long - the first character "G"; the rest,
   a number in the current radix whose value equals that of .GSCNT,
   which starts out as 0 and is incremented before each gensymming.
   Thus, in each call, an unspecified gensymmed dummy
   will provide a unique label.
   If nullspecified, a gensymmed dummy has the null string as a value.
   Gensymmed dummies are treated differently when nullspecified
   or unspecified for compatability with old versions of MIDAS.
   In fact, the distinction between unspecification and nullspecification
   is made only to handle this case.

   Examples:

   DEFINE GENMAC \FOO,BAR
	   FOO,,BAR
   TERMIN

   GENMAC X+1,Y		;Both args specified nonnull.
   ;	X+1,,Y

   GENMAC X+1,,		;Second arg nullspecified.
   ;	X+1,,		;Nullspecified args are not gensymmed.

   GENMAC X+1		;Second arg unspecified.
   ;	X+1,,G00001

   GENMAC X+1		;Note uniqueness of gensyms.
   ;	X+1,,G00002

   GENMAC()		;Both args unspecified
   ;	G00003,,G00004


   GENMAC(,)		;First arg nullspecified; second, unspecified.
   ;	,,G00005
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fq3q7$5kp1i$1@ID-63952.news.dfncis.de>
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> There's pretty extensive experience with myriad users
> and multiple implementors over a really long time (in
> "contemporary programming language use" terms) to suggest
> that the reason no one is "evolving" the CL macro system
> is that it works just fine.

Thanks.  That's my point of view too.  In fact, I stated so specifically at the
top of one of my messages.
All I was trying to do is to explain why certain code was more complex than
average.
When someone asked me, I tried to explain the difference between a
transformation in meaning and a textual transformation, and I guess at that
point some people started seeing Scheme monsters along the way and got out their
guns.

Now this whole "my Lisp is the perfect Lisp" thing saddens me a bit.  I am glad
the Scheme community resisted the ARPA pressure to merge with CL, and I do hope
EuLisp is not still-born, but even then, a mere three Lisps..

Maybe it is just old age, but in my experience the days before standardisation
were much more fun, when you wrote a Lisp with some neat feature and showed it
around, and looked at other peoples' Lisps and took their stuff seriously.

Oh, I know, some research is still going on, but it seems the gusto is gone, and
that is not because we have reached the status of "perfect language"..

--
Biep
Reply via http://www.biep.org
From: Janis Dzerins
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <87pucftibx.fsf@asaka.latnet.lv>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> Maybe it is just old age, but in my experience the days before
> standardisation were much more fun, when you wrote a Lisp with some
> neat feature and showed it around, and looked at other peoples'
> Lisps and took their stuff seriously.
> 
> Oh, I know, some research is still going on, but it seems the gusto
> is gone, and that is not because we have reached the status of
> "perfect language"..

As I see it: Common Lisp standard has not stopeed anything -- it's
just a solid foundation for us to build on. Everyone is free to
improve on it (although it's really hard for novices to come up with
something that might be an improvement).

-- 
Janis Dzerins

  If million people say a stupid thing it's still a stupid thing.
From: Biep @ http://www.biep.org/
Subject: Thoughts and sighs..
Date: 
Message-ID: <9fqfff$5leaq$1@ID-63952.news.dfncis.de>
"Janis Dzerins" <·····@latnet.lv> wrote in message
···················@asaka.latnet.lv...
> As I see it: Common Lisp standard has not stopped anything
> -- it's just a solid foundation for us to build on.

Oh, having CL is definitely a good thing, and of course it doesn't forbid
anybody to play around.  But the time when Interlisp was in a contest with
MacLisp, when to almost everybody's amazement Scheme(r) brought the
Planner/Conniver line back in the fold by showing that with lexical scoping
Hewitt's actors were identical to procedures, that time seems gone, and I think
too early.

I must confess that on the lexical scoping thing I used to be on the wrong side,
or rather defending having both (having programs such as this Prolog interpreter
that didn't need to pass along most of its arguments in the
backtrack-recursion), but the discussions were there, and there was an enormous
lot of creative energy pushing the barriers forward.  It seems most of that has
gone to the FP people (who talks about monads in the Lisp community?), and Lisp
seems to be petering out.

Other languages are (seemingly) overtaking it, and the power of Lisp that made
it run faster and thereby stay miles behind of the pack has been sapped.  It is
like the hare falling asleep because it is ahead of the tortoise.

Now maybe I am wrong, and exciting new developments are still leading to
improvements, but the only place where I see that happen is Scheme, and despite
SLib, Scheme is not real-world robust.  (Well, that's exaggerated, but there are
definite disadvantages to using Scheme in the Real World.)

My ideal vision would be the big bomber CL moving steadily forward, with a lot
of smaller satellite Lisps around it that cleared the way in front, and then CL
absorbing the space cleared by those satellites.  But I see only one satellite,
Scheme, which has its own set of satellites and is in fact (slowly and ever more
slowly) moving forward, but only in one of a host of possible directions, which
is not necessarily the direction CL should go.

Of course Lisp itself is a satellite of the ethereal ideal programming language,
having chosen to explore the untyped lambda calculus, but most of the activity
is happening by the typed lambda calculus people, and if their languages get
better than the best Lisp, research in untyped lambda calculus as a programming
language, or in program-as-data, will all but die when Lisp dies.

I don't care if a language dies because a successor is objectively better, but I
do care if that kills parts that are, or may be, better than corresponding parts
in that successor.

--
Biep
Reply via http://www.biep.org (which is down right now, but sending to any
username whatsoever at that domain will get to me).
From: Erik Naggum
Subject: Re: Thoughts and sighs..
Date: 
Message-ID: <3201014988278899@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> But the time when Interlisp was in a contest with MacLisp, when to almost
> everybody's amazement Scheme(r) brought the Planner/Conniver line back in
> the fold by showing that with lexical scoping Hewitt's actors were
> identical to procedures, that time seems gone, and I think too early.

  You are too puzzling a character for me to want to spend any time on, but
  just out of curiosity, since you refer to CLtL2 as the reference for
  Common Lisp, your attitudes and opinions must predate 1995 and not have
  evolved much since, and by the looks of it, you are still mired in the
  pre-1990 Lisp world, possibly even pre-1980.   Why is that comfortable
  for you when the rest of the Lisp world really _has_ moved on so much and
  so far?  Why are you pining for an irrelevant past?

  Or are you trying to prove my point when I say that Scheme is not a Lisp,
  that the Lisp that "Scheme is a Lisp" refers to is a really, really
  ancient Lisp that has absolutely no relevance outside of history lessons?

> I don't care if a language dies because a successor is objectively
> better, but I do care if that kills parts that are, or may be, better
> than corresponding parts in that successor.

  The very idea that anything is "objectively better" is simply ludicrous.

  I think you need a fundamental attitude readjustment.  Quit being a troll.

#:Erik
-- 
  Travel is a meat thing.
From: Frank A. Adrian
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <%zbU6.203$uJ6.214891@news.uswest.net>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> wrote in message
···················@ID-63952.news.dfncis.de...
> Maybe it is just old age, but in my experience the days before
standardisation
> were much more fun, when you wrote a Lisp with some neat feature and
showed it
> around, and looked at other peoples' Lisps and took their stuff seriously.

So what are you proposing?  If you have nothing to show around (and yes,
it's just as easy to build something now as in the old days - maybe easier),
then all you're doing is bitching.  Anyone who could show a system for doing
the equivalent of (or more than) the current CL macro system without (what
you perceive as) the cruft would probably be listened to.  So get cracking!
Otherwise, be still.

faa
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwr8wux4h1.fsf@world.std.com>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> Now this whole "my Lisp is the perfect Lisp" thing saddens me a bit.
> I am glad the Scheme community resisted the ARPA pressure to merge
> with CL, and I do hope EuLisp is not still-born, but even then, a
> mere three Lisps..

I don't think anyone thinks our Lisp is the perfect Lisp.

Personally, I don't think Scheme is a Lisp, but I say so mostly to help avoid
Scheme fanatics tinkering in Lisp or vice versa, since I think the two arise
from differing motivations.  I think languages that are out for different 
purposes will never satisfy each others' users, and ought not try.  But I also
think you can't critique a language very usefully if you have not tried to
use it and if you don't have some sense for how it is intended to BE used.

That's not to say some don't go back and forth between, and I don't mean to
say a person can be only in one camp.  Just that some people seem people deny
themselves a legitimate view of the other side by letting their prejudices
get in the way.

I'm not sure what to say about EuLisp.  I haven't tracked that.  But
certainly its name doesn't strike fear in my heart.  I do personally
think it's a separate language, perhaps more a dialect of Scheme than
Lisp, but that's just a subjective judgment.  I don't think CL is a
rock unto itself. I count gnu emacs lisp as a member of the lisp family,
and it's far from CL compliant.

All of that said, though, I don't think there's any way that CL people are
unwilling to hear criticism.  We thrive on it.  We share our troubles and
learn from them.  Although I consider myself an advocate of CL, I spend a
LOT of time here whining about its nits.  But that whining, whether from
me who's used it for a while or from a newbie who's just optimistic trying
it, needs to come from someone who is doing their best at whatever their
level of expertise to "get into it", and not merely "taking a moment to prove
to themselves what they already knew" or "testing out their theory that the
language couldn't work by running an example or two".

I'm speaking completely generally in all of the above remarks.  I haven't
followed this particular discussion in detail other than to note there were
some heated exchanges.  Please don't take any of my vague references to 
this or that kind of person as veiled references to the players here--I'm just
answering your remark in the general sense that it appears to call for.

I think there are communities that suffer from NIH syndrome.  I honestly
don't think the CL community does.  Someone (Joel Moses, I think) described
Lisp as a big ball of mud, to which you can add more mud without disturbing
the basic design (I've paraphrased a little); other langauges have been 
variously described by others using other metaphors that don't always tolerate
an influx of new ideas.  (APL, is the canonical example of a diamond, I think
it was, which cannot have other diamonds added to it without breaking.)

> Maybe it is just old age, but in my experience the days before
> standardisation were much more fun, when you wrote a Lisp with some
> neat feature and showed it around, and looked at other peoples'
> Lisps and took their stuff seriously.

I think you misunderstand a couple of things.

First, the particular dialect which is CL was formed out of a desire to not
haggle until doomsday about the primitive functionality.  It is a language
whose purpose is less to be "right" and more to be "standard".  That doesn't
mean it can't be found to have more optimal ways of doing things, it's that
in order to be changed, you'd have to show the platform was fundamentally
broken.

Second, this same thought was the conclusion of J13 a year or two ago when
it effectively decided to renew the standard rather than to change it.
I don't know anyone who didn't have an armload of things they want changed,
but no one could justify the COST of a change compared to the VALUE
of leaving it as is.  No one felt the language was materially unusable and
the general sense was that moving forward, not spinning our wheels on the
same old stuff, was the important thing.

I think if you are fair, and you divide the discussion along the lines of
"old" and "new" layers, you'll find all the same old stuff you may remember
from long ago.  I've seen a lot of healthy discussion about anything from
a  trivial function like partition-string to regexps to defsystem to xml
parsing to http handlers to you name it.  I don't think you see people saying
they have only one way to do things or that they aren't open to new thoughts.
But on the things that are STANDARD, you see them defend the present way
not because it's "right" but because it creates a balanced platform to do this
next round of work from.  

I've recently whined about the misdesign of pathnames (the problem of the
"hosted pathname", for example).  But you know what?  That's fixable by 
layering correct semantics atop the present semantics.  It's not fatal.
And I think it's better to count the overall system as working exactly
because it offers enough capability to rise above its little details of 
misdesign by monotonic addition.

> Oh, I know, some research is still going on, but it seems the gusto
> is gone, and that is not because we have reached the status of
> "perfect language"..

I think the gusto is not gone, but you phrase your remark as a perception
and I'm not going to assert that however it seems to you is not however
it seems to you.  I will, however, suggest you are misperceiving the
reality.

(I don't understand what any of this has to do with macro-writing in CL,
but I'll just let that slide.  If I care, I'll go read DejaNews.  You don't
have to replay the conversation.  It's just curious how far a conversation
can drift sometimes...)
From: Erik Naggum
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <3201013495412888@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> All I was trying to do is to explain why certain code was more complex
> than average.

  How do you measure complexity?  How do you know where the average is?

> Now this whole "my Lisp is the perfect Lisp" thing saddens me a bit.

  Why?  You have displaed a "my view is the perfect view"-attitude to
  almost everything else already?  Is it because you get counter-arguments
  that show that your view is _not_ perfect that it saddens you?

> I am glad the Scheme community resisted the ARPA pressure to merge with
> CL, and I do hope EuLisp is not still-born, but even then, a mere three
> Lisps..

  It saddens me to see someone with so little actual knowledge have such
  strong opinions.

> Maybe it is just old age, but in my experience the days before
> standardisation were much more fun, when you wrote a Lisp with some neat
> feature and showed it around, and looked at other peoples' Lisps and took
> their stuff seriously.

  The rebel nature has always had more fun before laws and regulation,
  which, amazingly, a majority of people actuall prefer, took away their
  "freedoms".  There are always people who can only have "fun" in a society
  without set rules, i.e., where they make up their own and can change them
  at will.  There are people who do not want others to have "fun" at all
  and make up so many rules that nobody can do anything unanticipated
  without breaking enough to hurt you.  Then there are people who grow
  tired of making up rules all the time, of ever-changing rules everywhere
  they go, of finding that the human capacity for memory is an _enemy_
  instead of a good friend in living productively, of living in fear of
  their long-range planning turning to an exercise in futility because the
  rules change so fast they cannot plan long-range at all.  (These people
  are not trying to do business in the Norwegian tax "climate", however,
  where politicians today are debating whether to withhold a tax break they
  promise us ten years into the future back in 1992, because, amazingly, it
  will reduce government revenue.)  In short, the only people who have more
  "fun" in a society without rules are the people who have enough power to
  make the rules.  If you recall such insignificant political events as the
  Magna Carta, which forced the then King of England to behave, or The
  Declaration of Independence, which forced the ruling England to withdraw
  their power to make rules over people in America, or the Universal
  Declaration of Human Rights, which basically sets limits to what the
  rule-makers can do to those who lack the power to make their own rules,
  so they have to _follow_ rules, you might begin to understand that the
  ability to make up rules as you go and to change everything all the time
  is not at all appreciated by those who try to follow them.  This also
  applies to programmers writing software in Lisp, companies basing all or
  some of their business plans on such software, or vendors who want to
  sell stuff to both of these parties, who consider the lack of agreement
  on the rules so hard to live with, but which the rebel nature finds so
  endearing because it is anathema to that dreaded anti-rebel concept of
  _responsibility_.  It is probably a mystery to you, so please feel free
  to believe me on faith, but societies, small and large, that have stable
  rules have prospered much, much more than societies with unstable rules.
  This seems to apply regardless of what the rules are, but bad rules tend
  to be unstable, so we are driven towards societies with stable rules.
  Globalization forces countries with irrational policies to reevaluate
  their rules because people are free to choose the rules they want to
  apply to their business and their personal lives.  Guess what kind of
  people find this so dangerous and fight it so much.  Precisely the kind
  of people whose main philosophy in life is to be on the rule-making end
  of the rules.  More reasonable people tend to consider both the maker and
  the follower of rules.

> Oh, I know, some research is still going on, but it seems the gusto is
> gone, and that is not because we have reached the status of "perfect
> language".

  The point with Common Lisp macros is that you can devise your own
  language if you want to.  Scheme has successfully been implemented in
  Common Lisp, for instance.  What was once called "research" is now more
  often called 'application programming" because the research has sort of
  "trickled down" into the masses.  An amazingly amount of AI stuff has
  taken this route and is no longer considered "AI" for that reason alone.
  _Compilers_ were once a very, very advanced "AI" research project.

  I think the evidence of what is going on in the other languages shows us
  that we have indeed reached the status of perfect language, but a lot of
  rebels of sometimes severely limited intellectual resources are never
  going to be satisfied with it, and insist on reinventing everything that
  is already in Lisp badly.  The little _actually_ new stuff that people do
  can also be done in or with Common Lisp.  More often than not, however,
  the "new" is in standardizing some of the environmental issues.  I guess
  it was a lot more "fun" before we had standardized environments, right?

  I want to build things.  That _includes_ languages, but not exclusively.
  People who build languages have a very hard time.  People who build stuff
  that _more_ than just programmers and researchers can use have a slightly
  easier time.  This has nothing to do with the perfectness of languages.
  
#:Erik
-- 
  Those who do not know Lisp are doomed to reinvent it.
From: David Thornley
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <13bU6.10022$Dd5.2846360@ruti.visi.com>
In article <··············@ID-63952.news.dfncis.de>,
Biep @ http://www.biep.org/ <·········@my-web-site.com> wrote:


>All I was trying to do is to explain why certain code was more complex than
>average.

I have a pet theory as to why some code is more complex than average.

It tries to do more complex things.

The CL macro facility is extremely powerful.  It allows you to write
a code generator with a very small amount of overhead.  It's like
writing a small piece of a compiler, without all the parser and lexer
stuff (which you don't need here).

This stuff is difficult.  I remember the first time I had to write
a program to generate simple source code.  I really botched the job,
and wrote and rewrote it before I got the basic idea.

Now, that took a lot of scaffolding.  (You try writing something
complicated in IBM 370 assembler without supporting structure.)
In CL, it takes almost no extra structure, and so the bulk of
what you'd normally write is removed, leaving only the core.  Since
the task is inherently difficult to do right, this leaves the macro
writer writing, and perhaps struggling with, a few lines of code.
The size of the macro written makes it look like it has to be
easy and simple, whereas it's complicated and can be difficult.

When there's a small language construct that is surprisingly difficult
and error-prone, there's a temptation to think that it's because of
some fault of the language.  This is usually true of most computer
languages I've used, but I think it false in this case.

>Now this whole "my Lisp is the perfect Lisp" thing saddens me a bit.  I am glad
>the Scheme community resisted the ARPA pressure to merge with CL, and I do hope
>EuLisp is not still-born, but even then, a mere three Lisps..
>
There's lots of things in the world that don't work very well, but which
nobody's come up with a better solution for.  Winston Churchill said
"Democracy is the worst form of government, except for all the other
ones."  I think this is one of those cases:  it isn't perfect, but
I don't have a better idea, and I haven't met anybody who did.

So, if you have an idea for a better way to write macros, or a better
way to teach how to write macros, please tell us.  If not, then I
think this is one of those cases of idealism that are just going to
be frustrated.

--
David H. Thornley                        | If you want my opinion, ask.
·····@thornley.net                       | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9gkkal$96qpl$1@ID-63952.news.dfncis.de>
"David Thornley" <········@visi.com> wrote in message
····························@ruti.visi.com...
> So, if you have an idea for a better way to write macros,
> or a better way to teach how to write macros, please tell us.

No, I think in CL macros should remain the way they are.  Standards should move
slowly, and the last word is definitely not yet out on macro writing.

There are a few changes I would argue for if there had been no standard as yet,
but then who hasn't :-)

The way of teaching that has worked best for me is:
- explain the basics,
- have people write a macro
- write a context in which the macro fails
- discuss.
- repeat the above till macros start being in shape.

I have found this to work better than the other way around (discussing the
pitfalls first).

Of course this does trigger the eternal question: but if Lisp is so much about
"the programmer shouldn't have to care" (as with memory management and the
like), then why do we have to care with all that here?

To which my answer is: research is still ongoing, and until it settles on a
clear plateau, it is no use changing the standard.
(Pointing to a few explorative implementations of different macro systems helps
here.  It helps people get a feeling of the issues that play.)

--
Biep
Reply via http://www.biep.org
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwg0cyt55v.fsf@world.std.com>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> "David Thornley" <········@visi.com> wrote in message
> ····························@ruti.visi.com...
> > So, if you have an idea for a better way to write macros,
> > or a better way to teach how to write macros, please tell us.
> 
> No, I think in CL macros should remain the way they are.  Standards
> should move slowly, and the last word is definitely not yet out on
> macro writing.
> 
> There are a few changes I would argue for if there had been no
> standard as yet, but then who hasn't :-)

Such as?
 
> The way of teaching that has worked best for me is:
> - explain the basics,
> - have people write a macro
> - write a context in which the macro fails
> - discuss.
> - repeat the above till macros start being in shape.

There is no standard for teaching.

However, as I recall, some work in automated teaching the Open University
agrees with you at least to some extent, for programming in general.
I vaguely recall that they did some tests in how to explain programmer
errors to people.  As I recall, they found that saying "you have a 
fencepost error", however nice that feels to an experienced programmer,
left the programmer confused.  I think, if I remember this right, the issue 
is that for any new concept a user is struggling to use, the user is not
fluent in the terminology which precisely describes and bounds the issues
of that concept, so appealing to that terminology only begs the questions
they have, and adds little insight.  They found, I believe, that just saying
"Your program fails for the following input: ...", while less abstract, was
more reliably going to cause a lightbulb to go on in the new programmer's
head.

I would add as an aside that this is probably a restatement of the claim by,
I believe, Minsky, which goes something like "you can't learn a thing unless
you almost already know it".  You probably have to have seen the bug in 
practice in order to really internalize a name for it.

> I have found this to work better than the other way around (discussing the
> pitfalls first).

Could be.  But this IS a statement about teaching technique, not language
definition, so is not at odds with anything in the language.

The language specification itself is not written to newbies.  It is only
a fortunate accident that as much of it as is readable is readable by newbies.
And while other people may name their books using names like "ANSI Common
Lisp", that doesn't mean they have an ANSI-approved teaching style.

> Of course this does trigger the eternal question: but if Lisp is so
> much about "the programmer shouldn't have to care" (as with memory
> management and the like), then why do we have to care with all that
> here?

I can make no sense of "all that" in this context.

Bernie Greenberg, at the MIT Multics Group, used to teach a course in
Lisp in which he used to always assert "a cons is an object that
cares".  But while programmers might not be supposed to care about GC
and might be supposed to feel warm and fuzzy about conses going around
caring for the things they point to, I don't think it would be
reasonable to generalize it to say "programmers must always care" or
"programmers must never care".

> To which my answer is: research is still ongoing, and until it settles on a
> clear plateau, it is no use changing the standard.

You've spoken only about teaching in this message, yet you have made
frequent use of the term "standard".  I see no relation, either in
practice nor any you've attempted to draw in the text.  I'll stop
short of drawing the perhaps-unwarranted conclusion that you are
confusing the standard with some teaching text or that you think there
can only be one way to teach it or that you think the standard somehow
inhibits the way it can be taught.

Instead I'll just ask: what's your point?

> (Pointing to a few explorative implementations of different macro
> systems helps here.  It helps people get a feeling of the issues
> that play.)

Implementations != languages.

Implementations don't decide languages.

Languages aren't decided on the basis of implementations.

One cannot have an "explorative implementation" of a language.
A language is a fixed thing.

One CAN explore the possibility of using a different language by allowing
an implementor to free him/herself of any concern about implementing any
particular language.

One CAN allow the implementor the freedom to believe it's their right or
responsibility to implement a macro system because someone forgot to.

But I think the truth is that there are several macro systems with pretty
well-defined semantics that each language shops among when choosing which,
if any, they will offer.  We can discuss the features of those in the
abstract, but we cannot discuss the efficacy of those in the abstract;
that is, we need to see how they work in the context of the language
environment where we might deploy them.  Consequently, you can't just point
to an "explorative implementation of a different macro system" unless
it's in an otherwise-CL  base and get really useful data about whether
that system would be good for CL.  The evaluation of what's good for CL should
be done  in the context of other features.

To do otherwise is to say "the arctic gets along fine without mosquitos,
so we should really try that in the rainforests of central america."  
Ecologies don't work that way.  And languages are ecologies.  Linguistic
features do not exist in isolation; they make other language features easier
and harder to get to, they aggravate problems or enhance strengths.  But the
way in which they do this is language/ecology-specific, not general to all
languages and all ecologies.
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9gl046$9o2a4$1@ID-63952.news.dfncis.de>
Kent, I know that you have disclaimed at some point that you don't read threads,
but in this case the relevant part of the thread is still in YOUR post even :-)

Mr. Thornley asked a double question
(1) If I have an idea for a better way to write macros, please tell us
--> To which my answer was:
    No, I think in CL macros should remain the way they are.
(2) If I have an idea for a better way to teach how to write macros, please tell
us
--> To which my answer was a short explanation of how I tend to teach CL macro
writing.

The two parts are different issues, addressing different parts of the double
question.
--
Biep
Reply via http://www.biep.org

"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> "Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:
>
> > "David Thornley" <········@visi.com> wrote in message
> > ····························@ruti.visi.com...
> > > So, if you have an idea for a better way to write macros,
> > > or a better way to teach how to write macros, please tell us.
> >
> > No, I think in CL macros should remain the way they are.  Standards
> > should move slowly, and the last word is definitely not yet out on
> > macro writing.
> >
> > There are a few changes I would argue for if there had been no
> > standard as yet, but then who hasn't :-)
>
> Such as?

I would argue for scoping rules within macros and outside of macros that are as
alike as possible, i.e. lexical scope as the default, but with the possibility
of special declarations.  This of course raises some name-space issues (special
variables having their own namespace outside of macros, whereas - in a
simplistic form of this proposal - special macro symbols would match lexical
items in other namespaces, but I am not going to start a discussion of that.  I
have already burned my fingers enough simply answering a question that I am not
going into a serious discussion of what I might have proposed if..

> There is no standard for teaching.

No, obviously..  Did anyone suggest there is one?
Sorry, I cannot connect this remark to anything else in a meaningful way..

> > I have found this to work better than the other way around (discussing the
> > pitfalls first).
>
> Could be.  But this IS a statement about teaching technique, not language
> definition, so is not at odds with anything in the language.

Indeed. See above.

> The language specification itself is not written to newbies.  [etc.]

I suppose the remainder of your message is a result of the misunderstanding I
tried to clear up above, so I'll refrain from commenting on it.  If I am wrong,
I'll no doubt hear it..  :-)
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfw66dtvil5.fsf@world.std.com>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> Kent, I know that you have disclaimed at some point that you don't
> read threads, but in this case the relevant part of the thread is
> still in YOUR post even :-)

I do usually read threads intact when I read them, but I don't read all 
of them.  Mostly I disclaim when I'm only spot-checking a thread, as with
this one.  I've gone back and re-read most of it by this point, so I'm a
bit better informed.
 
> Mr. Thornley asked a double question
> (1) If I have an idea for a better way to write macros, please tell us
> --> To which my answer was:
>     No, I think in CL macros should remain the way they are.
> (2) If I have an idea for a better way to teach how to write macros, 
>     please tell us
> --> To which my answer was a short explanation of how I tend to teach CL
>     macro writing.

The post you enclose suggests (perhaps bad use of language?) that
somehow if the standard were different, you would suggest writing
macros in a different way.  Yet you continue to evade the question of
how you want macros done differently.  Had you said how you wanted to 
change things, I perhaps could have offered an explanation of why we
don't do it that way.  By leaving this part vague, you effectively purport
to have superior knowledge and to suggest that we all are too fixed in our
ways to accept it.  I think that is conversationally unfair.

If you are going to decline to cite ways in which you would change the
language, please stop suggesting that there are these secret ways that
are going ignored.  I suspect they are not going ignored, but have been
carefully thought about and rejected, but we can't say without seeing an
actual, worked example.

This posture of yours is, I suspect, what so annoys Erik.  And at this 
point I can hardly say I blame him.

I'll be discontinuing my auditing of this thread unless some details
of the so-called problems with the macro system are cited.  I do not
accept "a different mechanism to solve the macro problem should have
been used" as a "problem description".  That's a "proposed solution".
Problem descriptions cite desires to do things that lead to problems.
Also, any fair alternative proposal also makes an attempt to also
acknowledge what costs are introduced into the system by taking the
alternate approach (that is, most cleanup issues talk not only about
Cost of Non-Adoption but also bout Cost of Adoption).

I did want to actually hear what you had to say, but there are only so
many rounds of evasiveness, whether accidental or intentional, that I
can take before it reaches a point of diminishing returns.  If the
point of this conversation was to tell this community about macro
hygiene, you can be sure that a number of the people making the voting
decisions were intimately aware of the entire macro hygiene issue as
it unfolded and carefully considered whether we should address the
similar situation in CL.  The conclusion on the basis of all factors
was that it was unnecessary, potentially destabilizing, expensive,
etc.; it made a few small number macros easier to write at the cost of
making a great many of our most important macros very hard to write.
Btw, those same simple macros could probably be made easier to write
through application of the existing macro technology to write a
substitution-macro facility; I doubt the same could be done easily in
reverse to make it easy to write macros like LOOP in a hygienic macro
ssytem by first just writing some other helpful, general-purpose macro
also in a hygienic macro system.
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9gn08n$9od1t$1@ID-63952.news.dfncis.de>
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> "Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:
> > Mr. Thornley asked a double question
> > (1) If I have an idea for a better way to write macros, please tell us
> > --> To which my answer was:
> >     No, I think in CL macros should remain the way they are.
> > (2) If I have an idea for a better way to teach how to write macros,
> >     please tell us
> > --> To which my answer was a short explanation of how I tend to teach CL
> >     macro writing.
>
> The post you enclose suggests (perhaps bad use of language?) that
> somehow if the standard were different, you would suggest writing
> macros in a different way.

All right, let me try for the umpteenth time
(1) No, I think CL macros should remain the way they are.
(2) I think there is still a whole lot to be done in macrology, and I don't
expect "the ideal macro system" any time soon.
(3) Because you specifically asked I gave a hint as to what I might have liked
to see different, but that is a completely separate topic, and given all the
buzz my simple question answering here has generated, I don't think I have the
time and energy to have such a discussion in this forum.

I simply answered a question, and then some people saw a non-existent red flag
with the unspeakable S***** word on it and started assuming I wanted to change
things.  Please don't try to find hidden agendas where there are none.

>  Yet you continue to evade the question of how you want macros done
differently.

Because I DON'T want them done differently.  Would that maybe explain my
evasion?

> Had you said how you wanted to change things, [...]

The remainder of this message seems simply to re-iterate the same misconception,
so I'll ignore it here.

In other subthreads of this discussion I may provide input on what a macro
system in general "should" or "should not" be, but that will be in the general
context of, say, Lisp1 vs. Lisp2 languages, and very definitely not in the
specific context of CL (even though at times that may be used as an example, of
course).
Don't expect anything new from me, because I am not involved in macro
research -- but I do think I know enough to answer the question I did answer.

--
Biep
Reply via http://www.biep.org
From: Huaiyuan
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <c6xlmmpdvxy.fsf@rac2.wam.umd.edu>
Kent M Pitman <······@world.std.com> writes:

> I would add as an aside that this is probably a restatement of the claim by,
> I believe, Minsky, which goes something like "you can't learn a thing unless
> you almost already know it".

It's Lenat, justifying the Cyc project, if I'm not mistaken.

"Learning occurs at the fringe of what one already knows."

- huaiyuan
From: Dorai Sitaram
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fs4mk$cf5$1@news.gte.com>
In article <···············@world.std.com>,
Kent M Pitman  <······@world.std.com> wrote:
>
>I think the Scheme community is puzzled by the fact that CL doesn't
>have a hygienic macro system and yet doesn't run into all kinds of
>problems as a result.  Usually this kind of "surprise" comes from
>momentarily making the mistake of assuming that the conversation can
>usefully proceed by idealizing the differences between the two
>languages as being "only this" and assuming that what keeps the
>conversation focused will not leave out critical information that
>makes the conversation meaningful.  It is impossible to have a
>conversation about macros without a conversation on namespaces and
>packages (and "hygiene" is as much about those other two issues as it
>is about macros).  Yet they mostly forget to bring them into play when
>looking at our macro system.  We in CL rely on the Lisp2ness and on
>the package system to protect us from name conflicts, and in practice,
>it does.  To my knowledge, having worked at several Lisp vendors and
>having used CL now about 2 decades years, people who know what they
>are doing reliably do not run into any problems with name collisions
>in CL.  The problem just doesn't come up.  The ecology works.

It is important to keep in mind that regardless of
where the spirit of exploration takes the Scheme
community, defmacro remains exactly as usable and easy
in a Lisp1 as in a Lisp2.  A Lisp1er would use the same
technique to avoid lexical-variable capture as a
Lisp2er would -- when you introduce a lexical variable
in the expansion, use a gensym.  If someone gets the
impression that a Lisp1 forces one into considering a
hygienic macro system any more than a Lisp2 does, that
impression is unwarranted.

--d 
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwiti6s21e.fsf@world.std.com>
····@goldshoe.gte.com (Dorai Sitaram) writes:

> ... A Lisp1er would use the same
> technique to avoid lexical-variable capture as a
> Lisp2er would -- when you introduce a lexical variable
> in the expansion, use a gensym.

Actually, I was more referring to the issue of what variables you
could use free.  In Scheme, I find using variables like LIST to be
dicey because I use that as a variable name and it requires me to 
know how a macro expands to know if I'm screwing it by using a pretty
variable name.  So I think there are some legit concerns in a Lisp1.

> If someone gets the
> impression that a Lisp1 forces one into considering a
> hygienic macro system any more than a Lisp2 does, that
> impression is unwarranted.

It might not be an all-or-none thing, but I think it can't be argued
that the probabilities of collision are higher.  Well, ... it can be
argued ...  I just don't think it will end successfully. ;-)
From: Dorai Sitaram
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9fvr3h$el4$1@news.gte.com>
In article <···············@world.std.com>,
Kent M Pitman  <······@world.std.com> wrote:
>····@goldshoe.gte.com (Dorai Sitaram) writes:
>
>> ... A Lisp1er would use the same
>> technique to avoid lexical-variable capture as a
>> Lisp2er would -- when you introduce a lexical variable
>> in the expansion, use a gensym.
>
>Actually, I was more referring to the issue of what variables you
>could use free.  In Scheme, I find using variables like LIST to be
>dicey because I use that as a variable name and it requires me to 
>know how a macro expands to know if I'm screwing it by using a pretty
>variable name.  So I think there are some legit concerns in a Lisp1.
>
>> If someone gets the
>> impression that a Lisp1 forces one into considering a
>> hygienic macro system any more than a Lisp2 does, that
>> impression is unwarranted.
>
>It might not be an all-or-none thing, but I think it can't be argued
>that the probabilities of collision are higher.  Well, ... it can be
>argued ...  I just don't think it will end successfully. ;-)

The fallacy in your argumentation is you assume that in
a selected time range (say, when he's writing the
expansion text of a macro) a Lisp1er forgets he's using
a Lisp1 and thinks he is using a Lisp2.   This is an
absurd assumption -- a Lisp1er is already fully
cognizant and acceptive of the idea that he's using a
Lisp1.  It, however, makes sense that a Lisp2er using a
Lisp1 might have a problem like this.  In essence, you
are saying that a Lisp2er would run into problems
working in a Lisp1 that he wouldn't in a Lisp2.  That
is indeed a legit thing to say but perhaps should go
without saying.

--d
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfw1yosh2o4.fsf@world.std.com>
····@goldshoe.gte.com (Dorai Sitaram) writes:

> The fallacy in your argumentation is you assume that in
> a selected time range (say, when he's writing the
> expansion text of a macro) a Lisp1er forgets he's using
> a Lisp1 and thinks he is using a Lisp2.   This is an
> absurd assumption -- a Lisp1er is already fully
> cognizant and acceptive of the idea that he's using a
> Lisp1.  It, however, makes sense that a Lisp2er using a
> Lisp1 might have a problem like this.  In essence, you
> are saying that a Lisp2er would run into problems
> working in a Lisp1 that he wouldn't in a Lisp2.  That
> is indeed a legit thing to say but perhaps should go
> without saying.

Well, I've spent serious time coding Scheme for work at some places
I've worked, so I tink I'm not just making it up from theory.  The
problem is that if someone else gives you a macro whose implementation
you don't know, you cannot know whether any variables you bind will
cause that macro not to work.

In CL, the common rule for macros is to never use a variable free,
only functions.  And additionally, if the macro has as its home
package the package you're in, you must know its implementation or
cannot bind any functions either; if it's a "foreign" macro, you can
bind functions because the package system will protect you.

In Scheme, there is no package system protecting you, nor is there a
separation of functions and values, so you are at risk every time you
bind a variable unless you know the expansion of every lexically contained
macro or unless you have a macro system with hygiene.

I don't see how this is fallacious.  What is the statement I have made that
is factually incorrect?
From: Dorai Sitaram
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9g2nag$g5e$1@news.gte.com>
In article <···············@world.std.com>,
Kent M Pitman  <······@world.std.com> wrote:
>Well, I've spent serious time coding Scheme for work at some places
>I've worked, so I tink I'm not just making it up from theory.  The
>problem is that if someone else gives you a macro whose implementation
>you don't know, you cannot know whether any variables you bind will
>cause that macro not to work.
>
>In CL, the common rule for macros is to never use a variable free,
>only functions.  And additionally, if the macro has as its home
>package the package you're in, you must know its implementation or
>cannot bind any functions either; if it's a "foreign" macro, you can
>bind functions because the package system will protect you.
>
>In Scheme, there is no package system protecting you, nor is there a
>separation of functions and values, so you are at risk every time you
>bind a variable unless you know the expansion of every lexically contained
>macro or unless you have a macro system with hygiene.
>
>I don't see how this is fallacious.  What is the statement I have made that
>is factually incorrect?

I question your unwillingness to consider that a
Lisp1 can have a robust, reliable approach to defmacro
that meshes with the Lisp1 environment.  You are very
willing to assume "common rules" for Lisp2, but somehow
it becomes unfair when a Lisp1 has its own protocol.   

To address your concern about the Lisp1 variable: A
Lisp1er who lexically shadows a variable understands
that the consequence of that is ... that that variable
will be lexically shadowed!  He is conditioned to
expect to be bitten if he doesn't respect this law.  

Actually, the problem is less severe than that.
Typically, binding non-primitive variables isn't going
to bite a user.  The defmacro body is not going to
introduce such variables free unless it is an act of
intent -- it is obviously expecting that variable to be
bound around the macro call! --, in which case the
capture was desired.  This only leaves the case
of binding primitive variables, which isn't something
that people should do without realizing that that's
what they want.  [1] 

As in Lisp2, a Lisp1 defmacro makes easy things
easy, and hard things possible, and there are
mechanisms to make things as safe as you need.   

--d

[1] In cases where a foreign macro has to be written to
be especially foolproof against global-variable
re-binding, you can do that too.  Use lexical scoping
to capture the global's definition-time binding,
and use ', to insert it into the expansion.  This is
not pretty, but it is not demanding of guru-level
cleverness, and you know you can do it if you are
really worried.  
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwpucbt320.fsf@world.std.com>
····@goldshoe.gte.com (Dorai Sitaram) writes:

> In article <···············@world.std.com>,
> Kent M Pitman  <······@world.std.com> wrote:
> >Well, I've spent serious time coding Scheme for work at some places
> >I've worked, so I tink I'm not just making it up from theory.  The
> >problem is that if someone else gives you a macro whose implementation
> >you don't know, you cannot know whether any variables you bind will
> >cause that macro not to work.
> >
> >In CL, the common rule for macros is to never use a variable free,
> >only functions.  And additionally, if the macro has as its home
> >package the package you're in, you must know its implementation or
> >cannot bind any functions either; if it's a "foreign" macro, you can
> >bind functions because the package system will protect you.
> >
> >In Scheme, there is no package system protecting you, nor is there a
> >separation of functions and values, so you are at risk every time you
> >bind a variable unless you know the expansion of every lexically contained
> >macro or unless you have a macro system with hygiene.
> >
> >I don't see how this is fallacious.  What is the statement I have made that
> >is factually incorrect?
> 
> I question your unwillingness to consider that a
> Lisp1 can have a robust, reliable approach to defmacro
> that meshes with the Lisp1 environment.  You are very
> willing to assume "common rules" for Lisp2, but somehow
> it becomes unfair when a Lisp1 has its own protocol.   

I wish you'd stop telling me what I am wililng to do and what I'm not.
This is simply factually in error and you are not in possession of
knowledge enough of how my brain works to say otherwise, so move on
and leave this point behind.  We MAY have a disagreement here, but it
is NOT over this.

> To address your concern about the Lisp1 variable: A
> Lisp1er who lexically shadows a variable understands
> that the consequence of that is ... that that variable
> will be lexically shadowed!  He is conditioned to
> expect to be bitten if he doesn't respect this law.  

You mean to say that no Lisp1-er, even in the automobile industry, ever
does:

 (defun foo (car) ...) / (define (foo car) ...)

without fear that some macro will use CAR free?  I don't agree.  I think
people want to use CAR in both Lisp1 and Lisp2, and the way this very
legitimate need is  implemented in Lisp1 is by "macro hygiene" and in Lisp2
it is implemented by having good programmers never FLET CAR, but they ARE
allowed to LET it.

Because Scheme cannot make this distinction, MY PERSONAL EXPERIENCE IN REAL
PROGRAM WRITING, and NOT just theory, tells me that I have to make assumptions
the macro writer for any macros in the definition of FOO and whether they
have done

  (defmacro next-car (cars) `(car ,cars))

In CL, this is simply not a problem because no one would think of doing FLET
of CAR.  However, people do [certainly I did] ROUTINELY bind names of system
variables and NOT for the purpose of changing the behavior of enclosed macros.
I consider in a Lisp1 that I am responsible for avoiding name collisions
with variables I can *see* but not with variables references to which might
be introduced in the expansion of a contained macro.  

THE WHOLE POINT of a macro is to hide its implementation, so that the user
will not have to know how it expands to use it safely.  This is easily done
in CL.  It is not easily done in Lisp1 without hygiene of some kind.

I'm sure it is POSSIBLE to write Lisp1 code that avoids this, but proving 
the correctness of such code involves someone doing a universal quantification
over use, because style rules are simply not adequate--ESPECIALLY because
Scheme also lacks symbol packages, which also help to separate exported CL 
macros from having conflicts with other environments.

Please offer a specific example of why what I have said is wrong.
From: Ray Blaak
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <ug0d6ud6t.fsf@infomatch.com>
Kent M Pitman <······@world.std.com> writes:
> You mean to say that no Lisp1-er, even in the automobile industry, ever
> does:
> 
>  (defun foo (car) ...) / (define (foo car) ...)
> 
> without fear that some macro will use CAR free?  I don't agree.  I think
> people want to use CAR in both Lisp1 and Lisp2, and the way this very
> legitimate need is  implemented in Lisp1 is by "macro hygiene" and in Lisp2
> it is implemented by having good programmers never FLET CAR, but they ARE
> allowed to LET it.

I am going from memory, so some Scheme freak can be sure to correct me, but I
believe the the normal hygienic macros to not capture free bindings at the
point of expansion, but rather at the point of definition.

That is, if CAR was available to the macro when the macro was defined, then
that is the CAR the macro will use when expanded.

Thus, the problem above will not occur.

There is a form of macro expansion that *is* dynamic (fluid-let-syntax or
something?), that will indeed capture the current bindings for free symbols,
so the problem will indeed occur for such macros. But with such macros, that
is the point.

> I'm sure it is POSSIBLE to write Lisp1 code that avoids this, but proving
> the correctness of such code involves someone doing a universal
> quantification over use

Lexical scoping at the point of macro definition neatly avoids the
problem. (As does Lisp2, as does gensym, ... -- no holy wars here, just
correcting what I believe to be an inaccurate understanding of Scheme macro
expansion.)

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
·····@infomatch.com                            The Rhythm has my soul.
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwwv6isx8y.fsf@world.std.com>
Ray Blaak <·····@infomatch.com> writes:

> Kent M Pitman <······@world.std.com> writes:
> > You mean to say that no Lisp1-er, even in the automobile industry, ever
> > does:
> > 
> >  (defun foo (car) ...) / (define (foo car) ...)
> > 
> > without fear that some macro will use CAR free?  I don't agree.  I think
> > people want to use CAR in both Lisp1 and Lisp2, and the way this very
> > legitimate need is  implemented in Lisp1 is by "macro hygiene" and in Lisp2
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > it is implemented by having good programmers never FLET CAR, but they ARE
> > allowed to LET it.
> 
> I am going from memory, so some Scheme freak can be sure to correct me, but I
> believe the the normal hygienic macros to not capture free bindings at the
> point of expansion, but rather at the point of definition.
> 
> That is, if CAR was available to the macro when the macro was defined, then
> that is the CAR the macro will use when expanded.
> 
> Thus, the problem above will not occur.

Is there an echo in the room?  This is exactly what I just said.  In a Lisp1,
it only happens if you have macro hygiene working for you, not otherwise.

Lisp2 does not have a hygienic macro system but this turns out not to matter
because the presence of (a) "packages" and (b) "multiple namespaces"
protects you.

> There is a form of macro expansion that *is* dynamic (fluid-let-syntax or
> something?), that will indeed capture the current bindings for free symbols,
> so the problem will indeed occur for such macros. But with such macros, that
> is the point.

Sure.  And such macros would have to be documented to do this.
 
> > I'm sure it is POSSIBLE to write Lisp1 code that avoids this, but proving
> > the correctness of such code involves someone doing a universal
> > quantification over use
> 
> Lexical scoping at the point of macro definition neatly avoids the
> problem. 

Unless I misunderstood, the question was NOT over whether Lisp1 could do
this at all--it can--but whether it requires macro hygiene.

Personally, I do not consider the macro hygiene solution to be a good
one because it has some ill effects I don't happen to like.  One
effect is that writing complex macros (like CL's LOOP) which aren't
simple substitution-effects is really quite hard.  The other effect,
which is less of a problem in the particular Lisp1 that is "Scheme and
all its features combined" than it might be in "a CL-like Lisp1" is
that the "painting" done by traditional Kohlbecker substitution
violates and then later attempts to "unviolate" quoted structure.  The
CL spec is slightly ambiguous on the issue of whether this can injure
code correctness, since there are situations where it's not certain
that coalescing/splitting is permitted.  If they are not permitted,
then a quoted object can be used for identity.  If they are used for
identity, then painting will destroy that identity.  Even if CL
doesn't permit quoted structure to be used for identity, there are
dialects in the possible space of Lisp1's that might not permit it.
Note that it is possible to construct a hygienic macro system that
doesn't violate quoted structure identity, but you have to go the
Bawden "syntactic closure" route.  I strongly prefer that mechanism
and would not have nearly as many objections to macro hygiene had it
been the Chosen Way.

> (As does Lisp2, as does gensym, ... -- no holy wars here, just
> correcting what I believe to be an inaccurate understanding of
> Scheme macro expansion.)

I don't recall trying to start a holy war.  What I heard, and maybe 
misunderstood, was assertions by some that macro expansion could work 
reliably in Scheme ABSENT hygiene, and I don't think that's so.
From: Ray Blaak
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <uelsp64nq.fsf@infomatch.com>
Kent M Pitman <······@world.std.com> writes:
> Ray Blaak <·····@infomatch.com> writes:
> 
> > Kent M Pitman <······@world.std.com> writes:
> > > I think  people want to use CAR in both Lisp1 and Lisp2, and the way this
> > > very legitimate need is  implemented in Lisp1 is by "macro hygiene" and 
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > in Lisp2 it is implemented by having good programmers never FLET CAR, but
> > > they ARE allowed to LET it.
> > 
> > I am going from memory, so some Scheme freak can be sure to correct me, but 
> > I believe the the normal hygienic macros to not capture free bindings at the
> > point of expansion, but rather at the point of definition.
> 
> Is there an echo in the room?  This is exactly what I just said.  In a Lisp1,
> it only happens if you have macro hygiene working for you, not otherwise.

Yes there is an echo. Sorry. That's what I get for too much speed reading of
large Usenet feeds.

> Note that it is possible to construct a hygienic macro system that
> doesn't violate quoted structure identity, but you have to go the
> Bawden "syntactic closure" route.  I strongly prefer that mechanism
> and would not have nearly as many objections to macro hygiene had it
> been the Chosen Way.

Do you have some pointers discussing the Bawden "syntactic closure" route?

> > (As does Lisp2, as does gensym, ... -- no holy wars here, just
> > correcting what I believe to be an inaccurate understanding of
> > Scheme macro expansion.)
> 
> I don't recall trying to start a holy war.  

You weren't. That's just me preemptively addressing certain classes of
responses, perhaps unjustifiably so.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
·····@infomatch.com                            The Rhythm has my soul.
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwlmmx7dr4.fsf@world.std.com>
Ray Blaak <·····@infomatch.com> writes:

> Yes there is an echo. Sorry. That's what I get for too much speed reading of
> large Usenet feeds.

Heh, no sweat.
 
> Do you have some pointers discussing the Bawden "syntactic closure" route?

I don't.  Maybe a web search would find something. But I develoepd the
same concept for myself around the same time and never published
anything on it, so I can sketch what *I* meant; I'm pretty sure
Bawden's was similar.  The essential difference between in and
painting was to place the burden on the macro implementor for
"closing" certain terms.

In effect, what you want to do "conceptually" is
 (defmacro first (x) `(,#'car ,x))
That is, you want to grab the "meaning" of car and expand into that.
Since this doesn't work for special forms, you would probably really
need something like
 (defmacro first (x &environment env) `(,(meaning-of #'car env) ,x))
In that way, 
 (first car) => (#<meaning-of #'car #<macro-env>> car)
and you don't get confusion.  It may feel a lot like painting, but it
does no tree-walking and no invasion of quoted structure. It also means
you could have a mention of meaning-of that was suppressed by quotation
until the right evaluation context.

There are various kinds of syntactic sugar you can put on this, like
having a code-walker that can turn
 `(car ,x)
into
 (list (meaning-of 'car env) x)
But this would again not walk quoted structure becuase it would want to
stop at quoted levels.

Yet another way for it to work is to have 
 (defmacro first (x) `(car ,x))
receive as an argument not CAR 
in the case of (FIRST CAR),
but instead a gensym or other special-typed object which was opaque
to the macro and which was, in effect, pre-painted.  In that way, 
  `(car ,x) => (CAR #:FIRST-ARG-7383)
What this makes difficult is the building of macros that care about the
"shape" of the actual argument; you cannot have a macro system that
receives proxies as args instead of the real arg UNLESS you also have
a function on the proxy that returns the ACTUAL argument also, thus letting
you pierce the veil of abstraction if you want.

So you can see there are about a half-dozen different ways you can implement
this, but the basic idea is to allow programmer-managed resolution of the
name-closing instead of system-managed resolution.
From: Dorai Sitaram
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9g31pq$gbn$1@news.gte.com>
In article <·············@infomatch.com>,
Ray Blaak  <·····@infomatch.com> wrote:
>Kent M Pitman <······@world.std.com> writes:
>> You mean to say that no Lisp1-er, even in the automobile industry, ever
>> does:
>> 
>>  (defun foo (car) ...) / (define (foo car) ...)
>> 
>> without fear that some macro will use CAR free?  I don't agree.  I think
>> people want to use CAR in both Lisp1 and Lisp2, and the way this very
>> legitimate need is  implemented in Lisp1 is by "macro hygiene" and in Lisp2
>> it is implemented by having good programmers never FLET CAR, but they ARE
>> allowed to LET it.
>
>I am going from memory, so some Scheme freak can be sure to correct me, but I
>believe the the normal hygienic macros to not capture free bindings at the
>point of expansion, but rather at the point of definition.

Ray, I think the topic in this subthread is about the
usability of a traditional defmacro in a Lisp1 setting.
One of the givens about a traditional defmacro is that
it doesn't close the free vars in its expansion text at
def time.  (Indeed, a defmacro that closed the free vars
at def time would be a less useful operator, and this
is very likely not a controversial point.)

R5RS-style macros are a whole nother ballgame.

--d
From: Dorai Sitaram
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9g2rlc$g9a$1@news.gte.com>
In article <···············@world.std.com>,
Kent M Pitman  <······@world.std.com> wrote:
>
>I wish you'd stop telling me what I am wililng to do and what I'm not.
>This is simply factually in error and you are not in possession of
>knowledge enough of how my brain works to say otherwise, so move on
>and leave this point behind.  We MAY have a disagreement here, but it
>is NOT over this.

OK.  I thank you for your time.  

--d
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwvgm2sx5k.fsf@world.std.com>
····@goldshoe.gte.com (Dorai Sitaram) writes:

> In article <···············@world.std.com>,
> Kent M Pitman  <······@world.std.com> wrote:
> >
> >I wish you'd stop telling me what I am wililng to do and what I'm not.
> >This is simply factually in error and you are not in possession of
> >knowledge enough of how my brain works to say otherwise, so move on
> >and leave this point behind.  We MAY have a disagreement here, but it
> >is NOT over this.
> 
> OK.  I thank you for your time.  

Just to be clear, I didn't mean for you to withdraw from the technical
discussion.  I'm curious what you have to say on technical matters.  I
simply don't want you making (false) assertions about me and my motivation
in this discussion.
From: Rob Warnock
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9g405e$fu98h$1@fido.engr.sgi.com>
Kent M Pitman  <······@world.std.com> wrote:
+---------------
| You mean to say that no Lisp1-er, even in the automobile industry,
| ever does:
|    (defun foo (car) ...) / (define (foo car) ...)
| without fear that some macro will use CAR free?
+---------------

I'm afraid that sounds like a "Have you stopped beating your wife?"
question to me. No sane Schemer would ever bind "car", with or without
macros!

Using the term "macro" here [and other places in your argument] is mostly
a red herring. Binding "car" with a "let" or as a formal parameter (which
in Scheme are equivalent) is *ALREADY* a such a problem in a Lisp1 that
everyone who writes Scheme seriously *already* has to worry about it,
completely independently of macros. In Scheme, you simply *MUST* memorize
the entire set of builtin primitives and refrain from naming variables
with the same names, or your code -- even if it runs correctly when written
initially -- will be totally unmaintainable. Can we just *stipulate* that,
please?

For anyone who is practiced & fluent in writing Scheme and *doesn't*,
therefore, routinely step on their own d... uh, toes, in my experience
adding "defmacro" to the mix does *NOT* make the problem any worse.
As long as both the macro writer and the macro user (writer of a call)
obey the implied contract (mandatory for sanity in a Lisp1) to not shadow
"well-known" global names ("car", "list", etc.), no *new* risks are added
by the introduction of (well-written) macros that are not already present
with the cut'n'paste nature of code development & maintenance.

That is, one *already* has to be careful when cut'n'paste-ing S-exprs
from one place in the code to another (since Scheme doesn't offer an
"inline" declaration) that you don't shadow either globals or local
bindings that are used in ways inconsistent with the cut'n'paste'd code.
Macros, in fact, can make this somewhat *easier*, since you can (using
"gensym") automatically avoid inadvertent capture of variable names
introduced by the macro expansion. This is so beneficial that one
*should* liberally use macros for inlining, rather than cut'n'paste!

+---------------
| I don't agree.  I think people want to use CAR in both Lisp1 and Lisp2,
| and the way this very legitimate need is implemented in Lisp1 is by
| "macro hygiene"...
+---------------

RED HERRING!!!  People who want to write maintainable code in a Lisp1
must *not* use "car" for anything but the system primitive, and must
exercise extreme discipline in choosing variable names *everywhere*,
even in the complete absence of macros... because you never know who is
going to be cut'n'paste-ing your code next week/month/year. If you allow
yourself to shadow "car" with a "let" or argument binding, it *WILL* come
back to bite you eventually (even in the complete absence of macros).

Eric often suggests that people not bring their Scheme preconceptions
to programming CL. The reverse is also true. People who write Scheme
live with the limitations of a Lisp1 all the time. Yes, it looks painful
to a practicing CL programmer (and it is), but it's there. It requires
a certain discipline in naming, which can (IMHO) be *assumed* to be
well-ingrained by the time the issue of "defmacro"-style macros comes up.
Nevertheless, people come from a CL context and say, "Oh, horrors, what
if somebody has bound 'car' in a context in which you call a macro that
uses it?" Well, that's would be a disaster, wouldn't it, even *without*
a macro, so Schemers simply "don't do that". [That is, Schemers bind
variable-bind "car" and "list", etc., about as often as CL'ers FLET
them -- practically never.]

Since that is true (or so I would claim), "defmacro"-style macros really
don't make things any worse in Scheme, and *can* even make life easier
(such as the above-mentioned inlining).

+---------------
| Because Scheme cannot make this distinction, MY PERSONAL EXPERIENCE IN
| REAL PROGRAM WRITING, and NOT just theory, tells me that I have to make
| assumptions the macro writer for any macros in the definition of FOO and
| whether they have done
|   (defmacro next-car (cars) `(car ,cars))
+---------------

I currently write a lot more Scheme than CL (though the ratio is becoming
somewhat smaller), and in my personal experience the general hazards of
a Lisp1 *absent* macros far dominate any problems introduced by macros.
To stay sane, you simply *MUST NOT* bind "car" (etc.) in Scheme code, with
or without macros. And if you adhere to that discipline already, "defmacro"
is no worse in Scheme than in CL, and your example is just as safe as any
other part of your program would be.


-Rob

p.s. Disclaimer (confession?): I never really got comfortable with the
R5RS macros. "Defmacro" is the *only* macro style I ever use in Scheme.
[All of the Schemes I use either have it or have something from which it
can be trivially defined.]  I understand "defmacro" ("code that writes
code", etc.), and understand how to get the kinds of hygiene I need from it.

-----
Rob Warnock, 31-2-510		<····@sgi.com>
SGI Network Engineering		<http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA

[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]  
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwg0cyyqu8.fsf@world.std.com>
····@rigden.engr.sgi.com (Rob Warnock) writes:

> Kent M Pitman  <······@world.std.com> wrote:
> +---------------
> | You mean to say that no Lisp1-er, even in the automobile industry,
> | ever does:
> |    (defun foo (car) ...) / (define (foo car) ...)
> | without fear that some macro will use CAR free?
> +---------------
> 
> I'm afraid that sounds like a "Have you stopped beating your wife?"
> question to me. No sane Schemer would ever bind "car", with or without
> macros!
> 
> Using the term "macro" here [and other places in your argument] is mostly
> a red herring. Binding "car" with a "let" or as a formal parameter (which
> in Scheme are equivalent) is *ALREADY* a such a problem in a Lisp1 that
> everyone who writes Scheme seriously *already* has to worry about it,
> completely independently of macros. In Scheme, you simply *MUST* memorize
> the entire set of builtin primitives and refrain from naming variables
> with the same names, or your code -- even if it runs correctly when written
> initially -- will be totally unmaintainable. Can we just *stipulate* that,
> please?

Nope.

To get an independent point of view on this, I approached Jonathan
Rees.  I have known him personally for many years, and know him to be
both a competent CL programmer who understands "the CL way" and a
well-respected and competent Scheme programmer who understands "the
Scheme way".  He's also a stickler for proper programming aesthetics.

Here's the reply I got from him...

- - - - - 

It's ridiculous to say that every Scheme programmer must memorize the
names of all Scheme builtins, just so that he can avoid using them for
his own purposes.  A very important goal was to make such memorization
or even knowledge unnecessary -- that's why the ability to redefine or
rebind the builtins is so carefully protected.  I know that I rebind
builtins often, and so does Sussman (he loves to rebind the arithmetic
operators); but I suppose neither of us is particularly "sane", so you
might want to take a broader poll to try to refute the claim about "no
sane Schemer".

Sussman articulated this idea from 1984 or earlier, and it is one
reason he refused to admit non-lexically-scoped macros to the language
-- he really wants to reserve the right to redefine anything at all,
including macros and special operators.  Hygiene solves the macro
redefinition problem, which is why he likes it.

It's unfortunate that the hygiene stuff has had such bad PR and poor
exposition - it and the pattern language both actually work (except
that I've never seen a happy escape syntax for use by macro-defining
macros).  I've recently put my Scheme of Things column on implementing
the hygiene part (not the pattern part) on line, by the way -- see
http://mumble.net/jar/pubs/.  If you combine hygiene with a module
system, you really don't need to keep track of internal details of
anyone else's code such as what names they define or bind.

And using macros for inlining is a big mistake.  You lose the ability
to trace, to easily pass as argument or return as result, and so on.
Scheme 48 has automatic cross-module inlining, so there are other ways
to achieve the same effect.

Scheme without a module system is a pain in the butt -- namespace
isolation is pretty important for building large systems.  I suppose
that you do have to exercise vigilance and write unnatural code if you
want to be able to combine subsystems written by different people (or
the same person at different times) in the same Lisp1 namespace.  I'm
glad I don't live in that world.
From: Dorai Sitaram
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9gl0lo$fct$1@news.gte.com>
In article <···············@world.std.com>,
Kent M Pitman  <······@world.std.com> wrote:
>[channeling Rees]
>
>It's unfortunate that the hygiene stuff has had such bad PR and poor
>exposition - it and the pattern language both actually work (except
>that I've never seen a happy escape syntax for use by macro-defining
>macros).  I've recently put my Scheme of Things column on implementing
>the hygiene part (not the pattern part) on line, by the way -- see
>http://mumble.net/jar/pubs/.  If you combine hygiene with a module
>system, you really don't need to keep track of internal details of
>anyone else's code such as what names they define or bind.
>
>...
>
>Scheme without a module system is a pain in the butt -- namespace
>isolation is pretty important for building large systems.  I suppose
>that you do have to exercise vigilance and write unnatural code if you
>want to be able to combine subsystems written by different people (or
>the same person at different times) in the same Lisp1 namespace.  I'm
>glad I don't live in that world.

There may or may not have been a misunderstanding, but
when I was talking about Lisp2 earlier in this thread,
I meant the 2 to mean the dichotomy between
symbol-function and symbol-value.  If the argument was
that the lack of this dichotomy makes hygiene
inevitable whereas the presence of this dichotomy does
not, I disagreed.  If the argument is that a Lisp with
a package system makes almost any aspect of
programming-in-the-large easier and more reliable than
a Lisp without one, I have no cause to disagree.  Modules
good.

When the Mr Rees's text (I am talking only about the
text as quoted by Mr Pitman, I know neither Mr Rees nor
Mr Pitman personally) extols _namespacing_, it seems to
mean a package/module system, not the function/value
dichotomy.  It is also interesting that it counsels
namespacing _in addition to_ hygiene!  This is
obviously rather at odds with, although not the direct
opposite of, the claim that namespacing obviates the
need for hygiene.

It looks like a person who wants hygiene will
want it even if he has namespacing; and if he doesn't
want hygiene he will not want it even if he doesn't
have namespacing.  Oy vey. 

--d
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfw7ky9vj9e.fsf@world.std.com>
····@goldshoe.gte.com (Dorai Sitaram) writes:

> 
> In article <···············@world.std.com>,
> Kent M Pitman  <······@world.std.com> wrote:
> >[channeling Rees]
> >
> >It's unfortunate that the hygiene stuff has had such bad PR and poor
> >exposition - it and the pattern language both actually work (except
> >that I've never seen a happy escape syntax for use by macro-defining
> >macros).  I've recently put my Scheme of Things column on implementing
> >the hygiene part (not the pattern part) on line, by the way -- see
> >http://mumble.net/jar/pubs/.  If you combine hygiene with a module
> >system, you really don't need to keep track of internal details of
> >anyone else's code such as what names they define or bind.
> >
> >...
> >
> >Scheme without a module system is a pain in the butt -- namespace
> >isolation is pretty important for building large systems.  I suppose
> >that you do have to exercise vigilance and write unnatural code if you
> >want to be able to combine subsystems written by different people (or
> >the same person at different times) in the same Lisp1 namespace.  I'm
> >glad I don't live in that world.
> 
> There may or may not have been a misunderstanding, but
> when I was talking about Lisp2 earlier in this thread,
> I meant the 2 to mean the dichotomy between
> symbol-function and symbol-value.

Yes.  Ignore that CL is really at least a Lisp4 (fn, var, tag, block).  
We always call it a Lisp2 for tehse discussions. ;-)

> If the argument was
> that the lack of this dichotomy makes hygiene
> inevitable whereas the presence of this dichotomy does
> not, I disagreed.  If the argument is that a Lisp with
> a package system makes almost any aspect of
> programming-in-the-large easier and more reliable than
> a Lisp without one, I have no cause to disagree.  Modules
> good.

See below.  Modules are not packages.
 
> When the Mr Rees's text (I am talking only about the
> text as quoted by Mr Pitman, I know neither Mr Rees nor
> Mr Pitman personally) extols _namespacing_, it seems to
> mean a package/module system, not the function/value
> dichotomy.  It is also interesting that it counsels
> namespacing _in addition to_ hygiene!  This is
> obviously rather at odds with, although not the direct
> opposite of, the claim that namespacing obviates the
> need for hygiene.

(I doubt that in any context where he refers to Scheme he is advocating
packages.  To my knowledge, he's never suggested that Scheme needs a
package system.  Only a module system.  But I'm not elected to speak
for him generally, I was just passing through the one message.  I am
just guarding against people reading too much into it.  My original
quoting of him was only to in defense of the Rob's suggestion that we
stipulate that Scheme code is expected to be unmaintainable if users
bind the names of system functions.  I didn't want to stipulate to that,
and I offered Rees's more neutral voice to suggest that probably some
core Schemers wouldn't stipulate to it either...)

> It looks like a person who wants hygiene will
> want it even if he has namespacing; and if he doesn't
> want hygiene he will not want it even if he doesn't
> have namespacing.  Oy vey. 

Well, I'll think about this more perhaps later, since it's an
interesting observation, but my first blush reaction is: packages and
modules are different.  They are used for the same purposes but their
characteristics differ substantially in ways directly relevant to the
macro expansion activity.

Packages are effectiveliy collections of pre-painted symbols.  Modules 
are not; they use lexical environment information but the SAME symbols
for new uses, which means that while you are constructing expansions,
you are, of necessity, creating genuine new opportunities for confusion
on every symbol, rather than only on the shared symbols.  And since the
shared symbols are felicitously the same MEANING, there really isn't an
opportunity to confuse their meaning either.

Surely this desire to reuse the selfsame objects must incur an
additional cost in the accounting department!  If Scheme's symbol
namespace is size N, CL's is size NxN since the package space is as
large as the symbol namespace, and somewhere in the "You Get Nothing
For Free" Department, that has to matter.
From: Dorai Sitaram
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9glf1b$fse$1@news.gte.com>
In article <···············@world.std.com>,
Kent M Pitman  <······@world.std.com> wrote:
>····@goldshoe.gte.com (Dorai Sitaram) writes:
>
>> It looks like a person who wants hygiene will
>> want it even if he has namespacing; and if he doesn't
>> want hygiene he will not want it even if he doesn't
>> have namespacing.  Oy vey. 
>
>Well, I'll think about this more perhaps later, since it's an
>interesting observation, but my first blush reaction is: packages and
>modules are different.  They are used for the same purposes but their
>characteristics differ substantially in ways directly relevant to the
>macro expansion activity.
>
>Packages are effectiveliy collections of pre-painted symbols.  Modules 
>are not; they use lexical environment information but the SAME symbols
>for new uses, which means that while you are constructing expansions,
>you are, of necessity, creating genuine new opportunities for confusion
>on every symbol, rather than only on the shared symbols.  And since the
>shared symbols are felicitously the same MEANING, there really isn't an
>opportunity to confuse their meaning either.
>
>Surely this desire to reuse the selfsame objects must incur an
>additional cost in the accounting department!  If Scheme's symbol
>namespace is size N, CL's is size NxN since the package space is as
>large as the symbol namespace, and somewhere in the "You Get Nothing
>For Free" Department, that has to matter.

Sorry about collapsing technical terms on you.  Yes, I
realize packages (different string->symbol mappings)
aren't modules (different symbol->meaning mappings),
although I'll admit to having slipped into
thinking of packages in terms of purpose rather
than specification, i.e., as intended to help divide
one's program into "modules" (informal meaning).   

I look forward to hearing about the interesting
implications that a package system and defmacro hold
for each other.  I don't know that they are all good
-- since packages destroy the Eden of naive
symbol manipulation and modules don't.  However, once
one learns to conscientiously substitute string
manipulation for symbol manipulation, the caution
against packages diminishes considerably.

--d
From: Gareth McCaughan
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <slrn9isohk.1snc.Gareth.McCaughan@g.local>
Kent Pitman wrote:

[Dorai Sitaram:]
> > It looks like a person who wants hygiene will
> > want it even if he has namespacing; and if he doesn't
> > want hygiene he will not want it even if he doesn't
> > have namespacing.  Oy vey. 
...
> Surely this desire to reuse the selfsame objects must incur an
> additional cost in the accounting department!  If Scheme's symbol
> namespace is size N, CL's is size NxN since the package space is as
> large as the symbol namespace, and somewhere in the "You Get Nothing
> For Free" Department, that has to matter.

I am unconvinced. I agree that the package system makes
the CL namespace better than Scheme's (or, to avoid angst,
better than CL's would have been without packages), but
it's not a matter of (> (* N N) N). In this context,
(= N (* N N)), near enough: the two namespaces are in
bijection under, say, the operation (package, symbol)
-> hack(package) + "--" + hack(symbol), where hack(x)
replaces n consecutive "-"s with (n+1) of them provided
n > 1.

What the package system buys you is not greater size
but abbreviation and isolation, which mean that you
only need to look at a small part of the namespace at
any time. It's a mechanism for focus, not for expansion
as such.

-- 
Gareth McCaughan  ················@pobox.com
.sig under construc
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwithte5m8.fsf@world.std.com>
················@pobox.com (Gareth McCaughan) writes:

> What the package system buys you is not greater size
> but abbreviation and isolation, which mean that you
> only need to look at a small part of the namespace at
> any time. It's a mechanism for focus, not for expansion
> as such.

Actually, that it is (* N N) is important because it means as part
of the focus that you only have to know the about the macros in the N 
symbols that belong to you, not the macros in the N^2-N that don't
belong to you.  That's different than an unhygienice Lisp1, where
you'd have to know about the macros in all all N*M symbols of the M
loaded modules, because the package system wouldn't be protecting you.
From: Gareth McCaughan
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <slrn9iviro.9a9.Gareth.McCaughan@g.local>
Kent Pitman wrote:

> ················@pobox.com (Gareth McCaughan) writes:
> 
> > What the package system buys you is not greater size
> > but abbreviation and isolation, which mean that you
> > only need to look at a small part of the namespace at
> > any time. It's a mechanism for focus, not for expansion
> > as such.
> 
> Actually, that it is (* N N) is important because it means as part
> of the focus that you only have to know the about the macros in the N 
> symbols that belong to you, not the macros in the N^2-N that don't
> belong to you.  That's different than an unhygienice Lisp1, where
> you'd have to know about the macros in all all N*M symbols of the M
> loaded modules, because the package system wouldn't be protecting you.

We are in violent agreement.

-- 
Gareth McCaughan  ················@pobox.com
.sig under construc
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9gko6a$9l09t$1@ID-63952.news.dfncis.de>
"Rob Warnock" <····@rigden.engr.sgi.com> wrote in message
···················@fido.engr.sgi.com...
> Schemers bind variable-bind "car" and "list", etc.,
> about as often as CL'ers FLET them -- practically never.

Except, of course, to change the meaning of the primitives (e.g. to install a
tracing version).

> (such as the above-mentioned inlining).

I think to a Schemer, inlining is something the compiler should worry about, and
cutting'n'pasting of code is "writing the same thing twice" -- an absolute no-no
in Scheme.  If you feel tempted to write the same code twice, refactor!

--
Biep
Reply via http://www.biep.org
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9gkls3$9htio$1@ID-63952.news.dfncis.de>
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
  [About name clashes in macros.]
> It might not be an all-or-none thing, but I think it can't be argued
> that the probabilities of collision are higher.

Yes, it is a difference of degree.
As far as I can fathom, the real problem is what RPG calls the "Worse is better"
vs. "The right thing".

I suppose no-one will seriously disagree with the statement that Scheme is more
in the "The right thing" camp, and CL in the "worse is better" camp.  Even a low
probability is wrong if it can be reduced to zero, and the programmer shouldn't
have to deal with that explicitly, a Schemer would argue.
The probability is pretty low to start with, the CL replies, it is even lower
because we have a second namespace, and to make it still lower we have
introduced a third namespace, packages.  (For a Schemer, these are basically
glorified let constructs, of course, so this is a partial implementation of
lexical scoping for macro variables.)

Oh, and you know this, of course, but probably some others don't: lexical
scoping and hygiene are two separate issues in macrology.

--
Biep
Reply via http://www.biep.org
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfwelsiyqjt.fsf@world.std.com>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@world.std.com...
>   [About name clashes in macros.]
> > It might not be an all-or-none thing, but I think it can't be argued
> > that the probabilities of collision are higher.
> 
> Yes, it is a difference of degree.  As far as I can fathom, the real
> problem is what RPG calls the "Worse is better" vs. "The right
> thing".
 
Probably.  We mostly get beaten up for being called The Right Thing by
other languages, so it's refreshing to see we sometimes, even if only
relatively, employ the strategy touted to win in practice, rather than
only the one touted to lose in practice, as we are more commonly
accused of. :-)

> I suppose no-one will seriously disagree with the statement that
> Scheme is more in the "The right thing" camp, and CL in the "worse
> is better" camp.  Even a low probability is wrong if it can be
> reduced to zero, and the programmer shouldn't have to deal with that
> explicitly, a Schemer would argue.

Correctly written CL code has probability zero.  Not near zero.  IF
you follow the appropriate style guidelines, you do not risk a problem.
Period.

I agree there are ways you can use the operators to make trouble for
yourself, but those are just opportunities for tightening what is and
is not legal in a future standard.  (We have the independent problem
that the text of the standard needs not to be changed right now, for
economic reassons, because there is nothing sufficiently wrong with
it.  But it is practically sufficient to say "consult a style guide".)

> The probability is pretty low to start with, the CL replies, it is
> even lower because we have a second namespace, and to make it still
> lower we have introduced a third namespace, packages.  (For a
> Schemer, these are basically glorified let constructs, of course, so
> this is a partial implementation of lexical scoping for macro
> variables.)

The issues is not probilistic. 

Probabilities were raised in an unrelated area.

> Oh, and you know this, of course, but probably some others don't: lexical
> scoping and hygiene are two separate issues in macrology.

But lexical scoping + namespacing + correct style is adequate to implement 
reliable hygiene.
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in a perfect world
Date: 
Message-ID: <9gppvk$ada5b$1@ID-63952.news.dfncis.de>
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> We mostly get beaten up for being called The Right Thing by
> other languages, so it's refreshing to see we sometimes, even if only
> relatively, employ the strategy touted to win in practice, rather than
> only the one touted to lose in practice, as we are more commonly
> accused of. :-)

Oh, not by Schemers, I can assure you.  :-)  How can deciding by majority vote
ever be The Right Thing?  We can only know it is The Right Thing if is is
PROVABLY the right thing, and if it is provable then the proof will be
universally convincing, so obviously voting by unanimity is The Right Thing -
right?

[A side note to people unaware of the background: The unanimity rule of Scheme
standardisation has basically brought that process to a grinding halt.
Development in these areas is now mainly happening through SRFIs that use a more
pragmatic approach.]

> Correctly written CL code has probability zero.  Not near zero.  IF
> you follow the appropriate style guidelines, you do not risk a problem.
> Period.

In order not to make this a tautology, I take "Correctly written CL code" to
mean "code that follows this established set of guidelines".

Now these guidelines include (roughly)

(a) . As a macro writer, use (gensym) for variables that shouldn't clash.

(b) . As a marco writer, use packages, and be careful within your own package
    . As a macro user, don't redefine of rebind indiscriminately.

Now, is't that an implementation of
(a) Use poor man's hygiene
(b) Use poor man's lexical scoping?

In a perfect world (i.e. I am NOT proposing that anything change in CL),
wouldn't an as yet nonexistent macro system deal with these things, without
witholding you from breaking either if you need to?

Or do you see a definite advantage in the system defaulting to dynamic scoping
and no hygiene, and the macro writer (user) doing (refraining from) some work to
achieve them if needed, rather than the macro writer doing some work if they are
unwanted?
For functions, Lisp has basically made the move from dynamic to lexical as
default - is there a fundamental reason not to have it that way for macros?

I think that is what the "Right Thing" question boils down to.

(Just to make sure again: so I am NOT talking about any specific implementations
for hygiene or lexical scoping, and especially not claiming that Scheme here has
made the right choice.  I am trying to establish whether research towards
lexical scoping and hygiene is going where the light is.)

--
Biep
Reply via http://www.biep.org
From: Frode Vatvedt Fjeld
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <2hy9qq5ae9.fsf@dslab7.cs.uit.no>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> I suppose no-one will seriously disagree with the statement that
> Scheme is more in the "The right thing" camp, and CL in the "worse
> is better" camp.

I don't think the "worse is better" argument applies here at all.

-- 
Frode Vatvedt Fjeld
From: Erik Naggum
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <3200915097859686@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> Erik, would you please go away?

  No, "Biep @ http://www.biep.org/".

  It is mot my fault that you expose your ignorance and your arrogance
  about what you do not understand.  You are one of those who think they
  have nothing more to learn and instead spend your time blaming what you
  have not studied for the fact that you do not understand it properly.

  It has been obvious for quite a while that you are here only to talk, not
  to listen, not to learn, not to appreciate contrary opinions and views.
  I suggest that you retreat to your Scheme world and enjoy yourself
  instead of wasting your time here, being as you are the one to suggest
  that people go away.

  You are making a problem look much harder than it is because you have
  failed to understand it.  It behooves a critic to be well educated.  You
  are not in the topic at hand.  Maybe you are so "educated" in other
  things you actually believe you do not have to know specifics, anymore,
  but then that is the problem in this debate, not the issues at hand.

  Just write the macros that produce the effects you want.  Publish them.
  It is actually that is.  The fact that you can is the strength of the
  Common Lisp macro system.  The fact that you _cannot_ do this in a
  syntactic closures system is a weakness of that system.  The fact that
  you might have to is not a blemish or a weakness of a language that was
  expressly designed to let people build their own tools within it.  If you
  want a language that _enforces_ what you think is right, that language is
  not Common Lisp, and the community you should talk to is not the Common
  Lisp community.

#:Erik
-- 
  Travel is a meat thing.
From: Paolo Amoroso
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <A9QfO6iYM5dKIu4bef2vw6afGUYK@4ax.com>
On Thu, 7 Jun 2001 10:50:24 +0200, "Biep @ http://www.biep.org/"
<·········@my-web-site.com> wrote:

> (http://www.brabandt.de/html/jargon_49.html).  I think the very fact that
> there are macro gurus indicates that there is a problem: the basic notion

So what? In all human activities there are both novices and gurus.


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Thomas F. Burdick
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <xcvk82llbkv.fsf@famine.OCF.Berkeley.EDU>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> There is a subtle but fundamental difference between the notions of 'fresh
> variable' and '(gensym)'.  The latter is a kluge to arrive at the former
> (or the right thing to do in other contexts, of course).

Yes there is a difference between a call to `gensym' and the notion of
a "fresh variable" -- as Pierre pointed out, `gensym' is a low-level
tool.  If you don't like writing your macros at that low of a level,
don't.  Write yourself some tools and never type the sequence "gensym"
again.  I actually type "gensym" maybe 1 in 500 times I use an
uninterned symbol in a macro.  Once in a while I need to call `gensym'
directly, the rest of the time, I use a little utility that walks the
code my macro returns and replaces symbols looking like =foo with
uninterned symbols.  It took a couple minutes to write.  But I'd be
really annoyed if I didn't have access to the low-level `gensym' on
those occasions when I need it.
From: Pierre R. Mai
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <87elstsmkz.fsf@orion.bln.pmsf.de>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> "Pierre R. Mai" <····@acm.org> wrote in message
> ······················@orion.bln.pmsf.de...
> > In what way do you feel that writing (serious) macros in CL
> > involves 'a lot of "fighting the system"'?

[...]

> (2) Macros are (or should be) about meaning one thing when you say
> another -- not necessarily about transformations, even though the notions
> come close.  (To appreciate the difference, see what C macros can do that
> they shouldn't..)  Let me just give a few examples:

Here I'd have to disagree.  Macros in Common Lisp _are_ arbitrary
source code transformations, nothing more and nothing less.  They are
not mechanisms that are geared to writing syntactic short-hand
notions, they are just a hook into the compiler/interpreter.  They are
source-level transformations of the sort you will find in the first
stage of a compiler.

In that way they are all powerful (every kind of transformation that
is computable can be implemented), and with that power come the
corresponding caveats.

Which is why I was surprised by your assertion that writing macros
involves a lot of "fighting the system", which I take to mean that you
have to circumvent _restrictions_ in the system to reach your goals.

If your claim were to be that the macro system itself provides too
little guidance and support to the writer of "simple" syntactical
convenience macros, I'd actually quite possibly agree.

I think there is a place (in a layered standard to ANSI maybe) for a
layer on top of the macro system, that implements something similar to
the R5RS-style or Dylan-style pattern-based macro systems.

But note that those are very different mechanisms with very different
goals and uses to those of defmacro-style "macros".

> There is a subtle but fundamental difference between the notions of 'fresh
> variable' and '(gensym)'.  The latter is a kluge to arrive at the former
> (or the right thing to do in other contexts, of course).

It is not a kludge, it is a lower-level tool, a building-block out of
which the higher-level tool will be built.  

> There is a difference between 'the list function' and '(list ...)'.  CLtL2
> has 'solved' the resulting problem by requiring that no built-in function
> can be redefined, but that is of course a weakness bid.

Of course there is a difference between 'the list function' and '(list
...)'.  The former is a function, the latter a form that is a function
call.

What you probably meant to state is that there is a difference between
the list function as described in the ANSI CL standard, and the
function that is invoked when the implementation encounters the form
'(list ...)'.  But if (eq 'list 'cl:list) (which is a reader issue),
then there is no such difference, because you are not permitted to
bind it, again according to the standard, as you state (though relying
on a document that never had any standing as a standard, in contrast
to CLTL1 and now the American National Standard X3.226).

Furthermore, as Kent has pointed out the same is true of any other
global function or special variable that is part of foreign code,
since the same implicit contract exists there, too.

And since "problems" only occur when you break that contract, which
requires direct action from you, this is a completely stable
situation.  When you override the definition of #'cl:list, you have to
expect the consequences.

> (3) So since the macro writer wants to state "whenever I say this I MEAN
> that", but the system wants to hear "whenever you say this, I should assume
> that you SAID that", macro writing necessarily involves fighting the
> system.  It is a lot like legalese: a lawyer is also a guru in bringing a

Not at all.  Fighting the system means having to work around
restrictions in the system, in order to achieve the results intended.
The problem you are running up against aren't the fault of the system:

The system states quite clearly that macros are a completely general
source transformation system.  But you want something _more_
restricted, in order to preserve you from having to think about
low-level issues.  In effect you are complaining that the system gives
you too little guidance, thereby allowing you to do something
different from what you wanted.

BTW I don't think that your description of what the macro writer wants
to is clearly defined.  The moment words like "MEAN" etc. crop up in a
definition of what a system should enable, we enter the land of DWIM
it seems to me.

> meaning across in a system that tends to look at texts, but it involves
> non-trivial phrasings, and often a lot more text than one might have
> thought.  If a non-guru draws up a legal document, it is likely there are
> loopholes.

Well, again, that isn't fighting the system.  When a non-programmer
draws up a specification for a system, it is likely to contain many
loopholes and inexactitudes.  That's why we have programmers (and
lawyers), which are capable of navigating the _necessary_ intricacies
of complex systems.

Of course for certain, simpler problems, the lawyer can offer you a
prewritten text, which can be used with a few simple changes out of
the box.[1]  Again, for certain "simple" macros, it might be
preferable to use a more restricted mechanism layered on top of
defmacro.  Indeed for many macros that people define it is often
better to use inlined functions.

And the nice thing about CL is that it allows the user to design and
implement such mechanisms to his liking, exactly because CL macros are
arbitrary source transformations.

> Does that help?  Again, if you are familiar with the system, the
> "macrolese" may come naturally, and even appear obvious, and definitely
> prove exploitable in ways that a "correct" solution would not be -- again
> the comparison with lawyers comes to mind :-)

If you were to refrain from using such words as "correct", and letting
your disdain for the legal system taint your argument, it might be
more persuasive.  It is clearly the case that defmacro is a "correct"
solution to the problem of arbitrary source to source transformations.
That you don't want a solution to this problem, but rather to a
slightly different problem, doesn't make defmacro incorrect, it just
means that you are missing a system that is a perfect fit to your
particular problem.  And the nice thing is that defmacro gives you the
mechanisms to create that system, which would be impossible if you
didn't have access to that lower-level mechanism.

Regs, Pierre.

Footnotes: 
[1]  In the legal world it is often still advisable to consult a
     lawyer, because non-experts are notoriously bad at evaluating
     whether the assumptions underlying the prewritten text apply to
     them or not.  Luckily this is somewhat simpler in the case of
     simple macros.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9gkrc1$9d81q$1@ID-63952.news.dfncis.de>
Yes, I think that our positions are actually very close, the main perceived
differences being linguistic rather than positional.

I look at a macro from a user point of view, because macros are written for
users.  I am under the impression that when a user calls a macro, <generic
inclusive> he generally has an idea of what the construct means rather than what
it does.  If I call the loop macro, I am telling the macro what it should do
with my data, not how it should transform what I tell it.  (The "telling" being
all the stuff I put in the macro call.)

If I am right in that supposition, what the macro system is providing (source
transformations) is not what people normally use it for (meaning
transformation).  That was the sense in which I used "fighting the system".

I expect it to be rare that a programmer, using (gensym) when writing a macro,
is actually interested in creating a nice fresh symbol.  Most of the time, what
he is really interested in (I presume) is that his variable doesn't clash.
Now luckily you can implement that behaviour in a sufficiently rich code
transformation system, but it is not the same thing, just like implementing a
call stack with local variable values is not the same thing as recursion.  The
one can implement the other, but it is an amount of extra work.

All I said originally was that this was the reason that some code was a bit more
complicated than people might at first thought expect - because you are
implementing things rather than simply using them.

This is of course no problem at all, because you can easily load a package with
tools that do this for you, so there we agree as well.  (My computer speaking
iX86 binary is no problem either, because I can install and run this nice CL -
life still has its rewards :-)

Se below for some replies to remarks of you.

--
Biep
Reply via http://www.biep.org


"Pierre R. Mai" <····@acm.org> wrote in message
···················@orion.bln.pmsf.de...
> Which is why I was surprised by your assertion that writing macros
> involves a lot of "fighting the system", which I take to mean that you
> have to circumvent _restrictions_ in the system to reach your goals.

O.K.  I hope I cleared that up

> If your claim were to be that the macro system itself provides too
> little guidance and support to the writer of "simple" syntactical
> convenience macros, I'd actually quite possibly agree.

It must be something with my English, because it feels as if everybody in this
newsgroup thinks I have some claim that something or other with CL is wrong.
Maybe standardising some simple safe system is useful, I am not sure.
I am always scary of adding something to a standard - it is quite hard to get
rid of later on.

> It is not a kludge, it is a lower-level tool, a building-block out of
> which the higher-level tool will be built.

O.K., I used "kludge" in the meaning of "parts that don't quite match at the
place where they meet" - the use vs. implementation discrepancy again.

> And since "problems" only occur when you break that contract, which
> requires direct action from you, this is a completely stable
> situation.  When you override the definition of #'cl:list, you have to
> expect the consequences.

Oh, with my CL mindset this is obvious.  But with my general Lisp mindset,
having such a contractual restriction in the first place is not completely
obvious.
But again: I definitely don't propose any change in the CL standard.  Maybe I am
sounding paranoid, but I have said this maybe about ten times now, and still at
times people seem to think I am proposing changes, or simply attacking CL, or
telling people to use another language.

> Not at all.  Fighting the system means having to work around
> restrictions in the system, in order to achieve the results intended.

Oh, that is a difference in semantics then.  For me it means "applying energy to
go one way whereas the natural inclination of the system would move me in
another way.  As in "fighting the Nazi army", or "fighting the current".  The
energy here being the explicit (gensym)s, etc.
Sorry for the misconception.

> BTW I don't think that your description of what the macro writer wants
> to is clearly defined.  The moment words like "MEAN" etc. crop up in a
> definition of what a system should enable, we enter the land of DWIM
> it seems to me.

I hope I did a bit better above.  "Mean" as in operational semantics of the
resulting program, "say" as in source transformation.

I kind of liked DWIM, by the way, even though it had a nasty habit of forgetting
a mistake just before I remade it..  :-(
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfw66e5zaly.fsf@world.std.com>
"Biep @ http://www.biep.org/" <·········@my-web-site.com> writes:

> There is a subtle but fundamental difference between the notions of 'fresh
> variable' and '(gensym)'.  The latter is a kluge to arrive at the former
> (or the right thing to do in other contexts, of course).

Actually, Lisp also has GENTEMP, but experience showed that it was
never adequate.  Peter Norvig and I, when putting together a coding
style presentation years back (parts of which I think is findable
somewhere by web searches) both noted and agreed that almost all uses
of GENTEMP are semantically flawed.  The problem with GENTEMP (which
might not appear in C because of lack of print/read consistency
leading to ephemeral environments that perhaps don't expose the
problem) is that you can't close over the space of things you wish to
have something be "fresh from".  That is, I can say "give me a fresh
variable" and you can do the same, but later we can merge our two
environments and find that we each thought a certain variable was free
and used it but that in the new, merged environment, it is not free.
You might say the probability was low that the two would be used
together, but it sometimes happened that people would proclaim such
uses SPECIAL, thinking after all that they owned the variable, and
then they would suddenly start failing to work in other people's
closures upon reload of stored code that had formerly been thought to
be a lexical closure.

> There is a difference between 'the list function' and '(list ...)'.  CLtL2
> has 'solved' the resulting problem by requiring that no built-in function
> can be redefined, but that is of course a weakness bid.

I don't see what this has to do with macros or weakness of anything.

> Lisp has fought hard to get rid of (default) dynamic scoping, but in macros
> this is still the default.  If your macro references a variable X, it just
> grabs whatever X happens to be available at the location where the macro is
> used.

Properly styled code therefore does not do this except where it can see the
entire space of usages and so prove it is safe.  This does not turn out to be
a weakness in experienced practice.  It is syntactically straightforward and
convenient for macro writers to write solid code in the face of this 
deficiency. 

> Like dynamic scoping for lambdas, people who have gotten used to
> that tend to like it, and indeed can proffer a whole battery of situations
> where this 'feature' can be exploited -- again the guru phenomenon.
> Normally you mean 'this variable' but have to write 'X', again not quite
> the same thing.  As with functions, lexical scoping (referential
> transparency) should be the default, with an option for dynamic scoping.

This is an assertion without foundation.

Certainly I absolutely agree with you that it is possible to take the 
position you are taking.  Nor do I deny that many do.  However, there are
other consistent world models that compete with this one and that are used
as well.  

There is also a price in terms of "complexity elsewhere" for the
approach you suggest.  Nothing prevents you from using macro
"painting" like Eugene Kohlbecker's macro systems in Scheme use, but
if you try it you will find that it doesn't work as well in CL as it
does in Scheme because a lot more things in Lisp than Scheme rely on
identity, and Kohlbecker's model paints not just program but data,
which injures some CL data structures that Scheme has no way of
talking about.

Further, there is a definite cost in terms of how hard it is to do things
that don't fit neatly into a simple substitution model.  Doing "hard 
computation" on a macro form in Scheme/Dylan is very much harder than in Lisp.
Macro writers have to think about these costs, too, which is why many of them
prefer the Lisp model.

If one was going to do a hygienic macro system for Lisp, the one I'd pursue
would be Alan Bawden (I think it was)'s "Syntactic Closures".  (I had a similar
theory worked out but he beat me to publication. Even so, I liked his approach
much better than Gene's painting system and was sad to see the painting
system win out.)

> (3) So since the macro writer wants to state "whenever I say this I MEAN
> that", but the system wants to hear "whenever you say this, I should assume
> that you SAID that", macro writing necessarily involves fighting the
> system.

So do ALL things that you choose not to like, whether or not they work.
No serious macro writer I know feels like he's fighting the system.
I very much enjoy writing macros.  I find their use simplifies my life
and I enjoy the process of making them.  I look forward to it.

> It is a lot like legalese: a lawyer is also a guru in bringing a
> meaning across in a system that tends to look at texts, but it involves
> non-trivial phrasings, and often a lot more text than one might have
> thought.  If a non-guru draws up a legal document, it is likely there are
> loopholes.

That same programmer is often going to write bad programs as
one-shots, without the macro system, too.  

But I have often said that the quality of being a programmer is being
a list-maker.  You are writing a full flowchart through a space, not just
a single path.  There is programming for the dabbler, where you just try
something and hope it works the one time you try it, and pat yourself on the
back.  But that's a different art form entirely.  Programming for serious 
programmers is about having industrial strength operators that stand up
under contract scrutiny.  And I daresay CL unhygienic macros will stand
up to Scheme hygienic ones just fine.  And probably both will beat out
C macros by leaps and bounds.

> Does that help?  Again, if you are familiar with the system, the
> "macrolese" may come naturally,

A skilled craftsman always knows his tools.  Would you come critique a 
carpenter's shop on the basis of how hard it is to use the 30 kinds of saws
when you can't see what the subtle differences are?  Because that guy is
surely just glad to have the right tool for each job as he comes up on it.
I'm sure he doesn't see it as woodlese.

> and even appear obvious, and definitely
> prove exploitable in ways that a "correct" solution would not be -- again
> the comparison with lawyers comes to mind :-)

As I went to write "There is no canonical out-of-context notion of correct."
I seem to recall someone (perhaps Erik) already making that point.
From: Daniel Barlow
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <87ae3hku9y.fsf@noetbook.telent.net>
Kent M Pitman <······@world.std.com> writes:

> Actually, Lisp also has GENTEMP, but experience showed that it was
> never adequate.  Peter Norvig and I, when putting together a coding
> style presentation years back (parts of which I think is findable
> somewhere by web searches) both noted and agreed that almost all uses

Would that have been the ``Tutorial on Good Lisp Programming Style''
at the Lisp Users and Vendors Conference, August 10, 1993

If that's the one you're referring to, people can get the slides from
Peter Norvig's site at <url:http://www.norvig.com/luv-slides.ps>.  It
refers to use of GENTEMP as one of a list of red flags: "... you do
not automatically have a problem in your code, but you should still
proceed cautiously".  A footnote refers to GENTEMP specifically as
having "no known good uses"


-dan

-- 

  http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources 
From: Kent M Pitman
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <sfw66e5xfmu.fsf@world.std.com>
Daniel Barlow <···@telent.net> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> > Actually, Lisp also has GENTEMP, but experience showed that it was
> > never adequate.  Peter Norvig and I, when putting together a coding
> > style presentation years back (parts of which I think is findable
> > somewhere by web searches) both noted and agreed that almost all uses
> 
> Would that have been the ``Tutorial on Good Lisp Programming Style''
> at the Lisp Users and Vendors Conference, August 10, 1993
> 
> If that's the one you're referring to, people can get the slides from
> Peter Norvig's site at <url:http://www.norvig.com/luv-slides.ps>.  It
> refers to use of GENTEMP as one of a list of red flags: "... you do
> not automatically have a problem in your code, but you should still
> proceed cautiously".  A footnote refers to GENTEMP specifically as
> having "no known good uses"

Yeah, that sounds about right. ;-)
From: Biep @ http://www.biep.org/
Subject: Re: Macro-writing in CL
Date: 
Message-ID: <9gl1a0$9dabv$1@ID-63952.news.dfncis.de>
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> never adequate.  Peter Norvig and I, when putting together a coding
> style presentation years back (parts of which I think is findable
> somewhere by web searches) both noted and agreed that almost all uses
> of GENTEMP are semantically flawed.

Hey, this may give your morale a boost (if needed):

The last several years my wife and I spent trekking through the inlands of
West-Africa, doing sociolinguistic research.  In practice that meant that we had
our backpacks, and imposed on ourselves a weight limit of 20 kg per person
(while trekking this became a lot more, because of research materials, food and
mainly the lots of water needed on the border of Sahel and Sahara.

I have never been able to dispense completely with all my Lisp stuff, and among
my 20 kg were some papers, among which a print-out of the overhead slides you
refer to.  (I didn't carry it along from village to village all the time,
however -- sorry :-)

--
Biep
Reply via http://www.biep.org
From: Erik Naggum
Subject: Re: To Paul Graham: Please put your books online.
Date: 
Message-ID: <3200870443762452@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> While PAIP is a great book, and can be used as an introduction to Common
> Lisp, it wasn't meant as such, and in fact the code in the book is
> inetntionally fairly basic, with a few exceptions, such as the stuff on
> macros (which, by the way, is mainly complex because writing a serious
> macro in CL involves a lot of "fighting the system").

  Thsoe who do not know or do not like the rules are always fighting the
  system regardless of what "the system" is, while those who know and like
  the system cannot generally fathom what it is that people _want_ to fight.

  The same goes with laws and regulations, codes of conduct, cultures, etc.
  Programming languages are social constructs.  Some people enjoy rebelling
  more than they enjoy living in a society.  Some are able to appreciate
  the societies they live in higher than what rebelling against it and its
  people would entail, regardless of whether they think everybody would
  appreciate whatever is on the other side of rebellion more than the
  present.  I, for instance, think it is far better to fight incompetence
  than to live peacefully with incompetent people.  Some people feel this
  way about drugs, abortion, communism, etc.  That macros in Common Lisp
  should be such an issue should come as a surprise to no one.  However,
  there is much, much less _force_ involved in having to accept macros than
  any of the other issues that cause similar reactions, so I have a really
  hard time understanding the underlying desires of the people who go nuts
  about "unhygienic" macros and the like.  Matter of fact, I think they are
  insane and fanatical because there is absolutel no _point_ in rebelling
  against macros.  Just understand them.  This is how it works.  Deal with
  it.  If you want to change the way they work, you definitely have to
  understand how they work today and all the discarded alternatives.

  If you want _any_ system to change, exploit it, do not fight it.
  Exploitation causes people who see undesirable consequences of their
  goals to review their means of achieving them, perhaps even changing
  their goals.  Fighting them causes people who are under attack to shut
  down all critical processes in self-preservation and defend themselves,
  regardless of the cost to their real goals.  (Exploitation of (massive)
  incompetence, however, is so unethical only Bill Gates and his like could
  do it for a long period of time.a)

  Now, how to exploit the system-fighters so they themselves implode?  I
  think Guile is an excellent way to exploit the dislike of Common Lisp and
  the adherence to "simpler" ways to do things.  With any luck, it turns
  into a _complete_ disaster before it has a chance of getting better.

#:Erik
-- 
  Travel is a meat thing.