I already covered that.  Most Scheme programs don't use call/cc heavily.

You can always pass something like this:
  (list kent 'person-1 rahul 'person-1)
where kent and rahul are hash tables, assoc lists, closures or
something.

Or you could define some global lookup table for 'kent and 'rahul, and
just pass '((kent person-1) (rahul person-1)).  I don't see any major
design flaw here.

Do you really think packages and property lists are prereqs for a
symbolic processing language?

Functions that manipulate other data types are first-order functions.
Functions that manipulate first-order functions are second-order
functions.  Am I using your terminology?

Absent definition, "higher order thinking" just sounds like "superior
thinking," making your post even more inflammatory.

 Dorai> I would say you have a Lisp _program_.

No, he's saying his robot doorbell has a Lisp runtime system
that is capable of running Lisp programs downloaded into it.

To cast things into provocative terms, I might say "what creates a bias
against higher-order thinking in CL is the people lined up with picket
signs outside the School of CL Programming's doorsteps saying "#' is ugly".
I don't think it's a necessary truth, but I think if you chant it enough,
you might make some headway.  And certainly you will make people feel like
they are offending someone by doing it.  But in the end, all that means is
you will cause people not to do higher order programming since that _is_
the syntax we do it in.  You will not cause a change in the language this
way.  Indeed, if you want to encourage higher order programming, you need
to get Nike to sponsort a set of signs for your picketers that say
"Just call it" and that ignore the syntax.

I realized after my post on "data hygiene" that the issue is that Scheme
provides two-argument EVAL but CL needs only 1-argument EVAL because the
"meaning" (read: the appropriate binding environment) of symbols to EVAL
is obvious just from the symbols.  Moreover, in CL  you can construct
mixed-use expressions that are tricky to compose in Scheme without layering
extra levels of expression.  Consider:  
  (eval '(cl:car (foo:bar alpha:*beta*))).
Now in Scheme you would have to first receive the environment in which
FOO and *BETA* were meaningful in order to do
  (lambda (foo-environment alpha-environment)
    (eval `(car ',(',(eval 'bar foo-environment)
                   ',(eval '*beta* alpha-environment)))
          (scheme-report-environment 5)))
or else you have to receive the actual values of those symbols from someone
who has done you the service of looking those things up
  (lambda (bar *beta*)
    (eval `(car ,(',bar ',*beta*)) (scheme-report-environment 5)))
or
  (lambda (bar *beta*)
    (eval `(car ,(bar *beta*)) (scheme-report-environment 5)))
[the second is more concise, but kind of does EVAL the favor of doing part of
its job for it beforehand].

First, I consider minimal competence of a programmer to include the
requirement that the programmer is not only aware of FLET and LABELS
but is aware of his own code and the consequences of his own code.

FLET and LABELS can certainly shadow names, _however_

 (a) if a programmer shadows his own names, I must conclude he intends to
     and I take this as the same kind of gesture as I would in scheme if
     one issued a "please capture" request to a hygienic macro system

 (b) if a programmer shadows another's names, they are declaring themselves
     implementor of that other programmer's code.  This is bad style, IMO,
     and in general should never be done in well-styled code.  (It is,
     however, sometimes done and sometimes even defensibly in an attempt
     to patch broken code.)

  Probably not.

You're certainly right that people who teach higher order functions
tend to come from a Scheme background, but this is not a technical
issue, it's an issue of historical preference ... er, "compatibility
with the past", that thing we're sometimes reviled for, but just not
Lisp's past. Someone else's past.  And, as you can see, there is value
to this.  Because it attracts a certain kind of person.  I just wish
you didn't keep all the knowledge of higher order functions bottled up
in the Scheme community by making it socially unacceptable for people
with that knowledge to socialize with people from other communities
without becoming hostile and evangelistic.  (Not you personally,
necessarily, though I think your personal rhetoric does sometimes have
this effect, even though I know it's not your intent.  But I mean "you"
collectively, meaning the "Scheme establishment".)

I would liken this problem to the problem of producing equal rights
among the races or the genders.  The problem between races or genders
arises in the first place becausee people like things in black and
white (if you'll pardon the unintended pun, by which I really only
mean "binary").  They want the good guys to be recognizable quickly
from the bad guys, and what could be easier than looking at skin color
or gender?  So forgetting who caused the first order effect, the fact
is that when the move for equality happened, the oppressors were of
one race and the oppressed were of another, or the oppressors were of
one gender and the oppressed of another.  So, heh, it was easy to tell
again who the bad guys were and who the good guys were.  And the
campaign for equality was mounted..  But wonder of wonders, the
problem wasn't solved overnight and now here's the mess: people are
still sometimes oppressed and people are sometimes not.  And _neither_
the oppressed nor the oppressors are any longer recognizable simply by
their "look".  At that point, we've seen that society gets into a mess
because some people start to realize that their allies come in both
kinds but others really preferred the battle lines to be easily drawn
and continue to behave as if the other gender or race were the enemy
because it's easier, in effect repeating the underlying sin against
which they are fighting: identifying a problem on the basis of a
superficial earmark rather than on the basis of who is really causing
what.

Now, one solution to this is for CL folks to claim that Scheme is a
Lisp and to claim we all are of the same "race" or "gender" because we
have the same look.  But that's a simplistic solution because if you
_really_ want to do outreach, and not simply rail against Bad Guys and
Good Guys who can be recognized on sight by some earmark that has
nothing to do with what you were complaining about, then at some point
you have to stop labeling people by how they look and you have to start
to say that what they do matters.

In Common Lisp, when you bind a special variable, or when you define a
function, there is a both a distinguished name (the symbol) and a
distinguished location (the function or value cell) where the value
is *required* to be stored, and these are available at top level.
So if you wrote a function `foo', the compiler will arrange for that
function to be in the function cell of the symbol `foo'.

To contrast this with Scheme, the compiler arranges it so that the
identifier `foo' will recover the current value of foo, but this
has nothing to do with the symbol `foo'.  Having the symbol `foo'
won't (in general) let you modify the value or function associated
with that name.

What this means is that the process of `linking' in Common Lisp
is required to maintain its data keyed by symbols.  This gives
one an API to the link info which is very handy for debugging,
introspection, and other advanced functionality.

The term 'keyword' is even used sometimes in place of 'symbol' in Scheme
bookmaking, underscoring the fact.

A patch was recently applied to the spec that said you can optionally
call READ and can interpret these rules to be about structure instead
of about syntax.  But that wasn't how it was for a long time.

(define foo (lambda (list prefix-fun)
   (add-prefix-fun-to-each-element)))

I don't think it's vastly unfair to compare this to the PL/1 sort of
thing of:

   IF IF = 5 THEN
     LET LET = 7
   ENDIF

[That might not quite be legitimate PL/1; hopefully the namespace
"collisions" are obvious enough :-).]

In contrast, it's kind of irritating that Common Lisp prevents me from
writing:

  (defun c2f (t)
     "Convert Celcius temperature to Fahrenheit"
     (+ 32 (* 9/5 t)))

  Please realize the difference between a requirement and a choice.

| Non-hygienic macros are definitely useful, but this bashing of hygienic
| macros doesn't seem right.

  It would not have been right in comp.lang.scheme.  You are not in
  comp.lang.scheme.  Over here, the obsessived-compulsive drive for
  "hygiene" is basically the object of some ridicule.  People who scrub
  (like doctors) before they eat, after they have been in touch with
  potentially disease-carrying materials (bonus points for overstating the
  potential), and, say, before touching anything valuable, like a book or a
  keyboard, may find like-minded people who consider this proper behavior,
  but they should also prepare themselves to have their views rejected by
  other people in sometimes hostile and sometimes derogatory ways.

  If you want some of the worst design decisions in Scheme to be protected
  from ridicule, choose comp.lang.scheme.  If you consider the derogatory
  implication of calling Scheme macros "hygienic" (which is just as snotty
  as we expect from the Scheme community), some ridicule back at a language
  that needs them because it dirties _itself_ should be par for the course.
  It is not Common Lisp that dirties itself and "lacks hygiene", it is what
  Scheme would do.  However, it is fairly obvious that the choice of the
  word "hygiene" is intended to communicate a superiority and instead of
  calling Common Lisp macros just "macros", they become "non-hygienic".
  What the hell is _that_?  Scheme freaks who hijack the premise for a
  discussion like that are bad people in my book.  Duane Rettig made a
  similar point about "proper tail recusion", which I chuckled when
  reading, because I had been taken in by the "improper" tail recursion
  that would be found in every other language.  Scheme is chock full of
  snotty terminology like that and it is, frankly, really, really annoying.

  I have read some of the most ludicrous nonsense about Common Lisp macros
  in comp.lang.scheme, where the common perception seemed to be that Common
  Lisp dirties itself _exactly_ the same way Scheme does, and it seems that
  Scheme freaks generally tend to think Common Lisp is nothing more than a
  variant of Scheme, that all the choices made by Scheme are also made by
  Common Lisp, except the ones that Common Lisp "missed" and that Common
  Lisp therefore sucks.  However, this is the problem with Scheme freaks
  when they wander outside their little playpen -- they do not _know_ that
  their terminology is Scheme-specific, they do not _know_ that they have
  made a huge number of design decisions that are different from other
  members of the Lisp family, and yet they have the _gall_ to parade their
  arrogant ignorance outside their chosen forum, huffing and puffing like
  some mighty little dragon.  _This_ is what has caused me to regard Scheme
  as an inferior language with inferior people in its community for so
  long, since no sane person would have to engage in such tactics to feel
  good about themselves and what they do.  "Look, I'm hygienic and you're
  not, and I'm proper and you're not" is not particularly mature rhetoric,
  but it _is_ a pretty good marketing strategy for something that is in
  need of such rhetoric.  But then the Scheme freaks want to pretend that
  what they do is _technical_ and _not_ political.  That is when the sheer
  dishonesty becomes a little too much to bear for non-fans of Scheme.

  But what can you do with a symbol in Scheme?  Can you read and write its
  value?  At least you can call a (first-class) function that has been
  pased to you.  Can you call a symbol in Scheme if its global value is a
  function?  If symbols are _only_ interned constant strings, I do not see
  the value of calling them "symbols" in the Lisp sense of the word.  This
  is one of the cost of flirting too much with the Algol family.

To my mind, macros are for providing nice syntax for things that you
find you want to do frequently but that would be tedious to type or ugly
to read.  Making simple examples of tail recursion look like iteration
does in other languages, for example.  Or hiding ugliness such as the
way you can use anonymous clases to implement anonymous functions in
Java -- which I think you said earlier today would be reasonably
acceptable if you could hide it in a macro.

In other words, what is it you want to do that the "lack of first class
symbols" (whatever that means) prevents you from doing?

The only *real* difference I can think of is that in CL one can do
something like (symbol-value (intern (read))), in other words, computing
the dynamically bound value of a symbol whose identity is not known at
compile time.  (If you know the value of the symbol at compile time then
(symbol-value 'X) is just X.)  Before R5RS this did not have a
straightforward Scheme equivalent.  (Now it's just (eval (string->symbol
(read)) (interaction-environment)).)  That's why I asked if this was
"really about special variables."  Since the answer to that is no I think
I'm still missing something.

(symbol-value x) == (eval x (interaction-environment))
(set x v) == (eval `(set! ,x value) (interaction-environment))

((eval f (interaction-environment)) arg1 arg2 ...)

or

(define (function f) (eval f (interaction-environment)))
((function f) ...)

Note that in the most common case where the identity of f is known at
compile time this becomes simply (f arg1 arg2 ...).

You can even do:

(define (funcall f . args)
  (cond ((symbol? f) (apply (eval f (interaction-environment)) args))
        ((procedure? f) (apply f args))
        ((vector? f) (apply vector-ref f args))       ;-)
        ((and (cons? f) (eq (car f) 'lambda)) ...)
        ...
        (else ... ) ; error - f is not callable

What do you see as the value (in the economic sense) of a symbol in the
Lisp sense of the word?  What can you do with a Lisp symbol that you can't
do with a Scheme symbol?  The only thing I can think of, even in pre-R5RS
scheme, is computing the dynamic binding of a symbol whose identity is not
known until run time.

  (make-instance <class> key1 value1 key2 value2 ...)

Now it either _is_ or _is not_ "good enough" to have keys be symbols.  
In CL it _is_ "good enough" because even a class made from two classes
made by different people who both want a SIZE keyword (e.g., it's both
a physical-object with width 19 (inches) and a screen-object with width
1024 (pixels) can be accomodated if they choose initargs of
  'physob:width 19 'drawing-area:width 1024
and moreover this can be done in a way such that within each of those
packages it isn't cumbersome because they just use
  'width 19
in the scope of their own little domains where they are not mixed together.
But to do (defclass the-big-picture (physob:monitor drawing-area:screen) ...)
would be a disaster if you're using symbols as the markers.  Yes, you
could say the whole make-instance protocol needs to be
  (make-instance thing '(drawing-area screen) 19 '(drawing-area width) 1024)
but in addition to just plain looking bad, you have slowed things down by
requiring an equal comparison instead of an eq comparison, and have introduced
the need to error check that I didn't do '(drawing-area screen ham-sandwich).

What Scheme does is not what you suggest but rather to define some

 (define-key width)
to expand to
 (define width (make-key 'width))
so that you do:
 (make-instance monitor width 19)
in the physob 'module' or
 (make-instance drawing-area width 1024)
in the drawing-area 'module' since you'll have done separate define-key
operations in both of those modules and you won't be colliding.  This means
if you want to mix these things you have to do
 (define drawing-area-width (value-from-environment 'width
                              drawing-area-environment))
 (define physob-width (value-from-environment 'width physob-environment))
and then you do
 (make-instance the-big-picture monitor-width 19 drawing-area-width 1024)
but the important thing to understand when you are all done with all this
hair is that you are not using symbols to guide you, but you have substituted
objects that are non-symbols to use as guides because symbols (as defined in
Scheme) don't compare well with EQ (a shared INTERN makes it too easy for them
to clash) and other objects do (because other objects are not interned).
So Scheme has made 'intern' a hindrance in certain cases, not a help.

 ((macsyma:mplus macsyma:simp) macsyma-user:$X 3)

I would write:

 (((macsyma mplus) (macsyma simp)) (macsyma-user $X) 3)

Forgive me if I'm already using s-expression for some other purpose than
what you've devised and if this causes me _substantial_ difficulty.

The whole point of symbols is to attach meaning to, but by interning all
symbols in the same package, that is, by not having a package system,  you've
robbed me of that.

The problem is that what you're saying is that an atom, to use it in the
original sense of the word, "an atomic unit of meaning", is really not
atomic.  

  No, it does not.  This is completely bogus reasoning.  And if it is your
  gripe with funcall, which seems to be a standard problem for Scheme
  freaks, even though they have _apply_ just as Common Lisp does, I have
  posted a macro called "with-functions" that effectively removes the
  funcall from sight and declares the variables as functions.  This should
  shift the bias back in the favor of "higher-order thinking".  That macro
  took me seven minutes to write, debug, and test (,', always confuses me).
  The distance between a Common Lisp and "higher-order thinking" is thus
  seven minutes of my time, and a google search and cut-and-paste for you.
  Please quit griping about this non-existing problem.

| In Lisp2, functions are usually bound in a different environment from
| other values, so Lisp2 programmers do not think of functions simply as
| values.

  This sounds totally bogus.  It certainly does not follow from the premise.

| Thus, for example, you can find examples of Common Lisp programmers who
| do not see the need for hygienic macros, claiming that function names
| cannot be shadowed.

  You can find examples of absolutely anything, and if you include jails
  and mental hospitals, even more, so this must be the weakest of all
  possible ways to express a criticism.

  It probably surprises you to learn that symbols in the common-lisp
  package cannot be defined or bound in a conforming program, so it is
  actually _true_ that "function names cannot be shadowed" (which is a very
  strange way of saying it. but I can sort of reverse-engineer the proper
  meaning from it).  At least a macro can expect the standard environment
  to apply, and I believe macros should do just that, and if they require
  additional environments, they should use symbols in a package over which
  the macro author has control.

  Because of packages and the restrictions on using symbols in the
  common-lisp package, there is no need to ensure that you have the right
  definition of any symbol in the common-lisp package with a function
  definition.  This, if you bind a variable "list" in Scheme, you have
  clobbered the standard function "list" for the body of the form that
  binds it, but if you try to name a local function "list" in Common Lisp,
  you already have an error in your program, one that a compiler should be
  reporting to you.

| Are they unaware of FLET and LABELS?  Probably not.  Probably they're
| just aware that FLET and LABELS are so seldom used as not to cause a
| problem for macro writers.

  Are you unaware of the restrictions on symbols in the Common Lisp
  package?  If you are, please see ANSI X3.226-1994 11.1.2.1.2.

| Why aren't FLET and LABELS used?  There are many reasons, but one is the
| cultural bias against higher-order thinking that results from a Lisp2.

  Nonense.  It does not result from a Lisp-2 at all.  That is just a stupid
  argument that Scheme freaks like to offer, and it is so goddamn _stale_.

| If you still don't get it, consider what it is like to simulate higher
| order functions using function objects in Java.  To call a function
| object f, you use a special syntax such as f.call(_) instead of writing
| f(_).  The .call can be viewed as a kind of cast that coerces from the
| value domain to the function domain.  Common Lisp's FUNCALL can be viewed
| as a similar coercion.

  HELLO!?  I PUBLISHED A MACRO THAT REMOVED FUNCALL FROM VIEW SO THAT YOU
  FUCKING OBNOXIOUS SCHEME FREAKS NO LONGER HAVE ANYTHING TO WHINE ABOUT!
  YOU MORONS HAVE SPENT *YEARS* WHINING ABOUT THIS, YET IT TOOK ME NO MORE
  THAN SEVEN MINUTES TO GET RID OF IT AND CONFLATE THE NAMESPACES FOR A
  SPECIFIC LIST OF VARIABLE NAMES.  What does this show, _other_ than that
  Scheme freaks are _much_ more interested knocking and denigrating Common
  Lisp than doing anything useful and constructive?

  If you still do not get it, figure out that Common Lisp has the power and
  capacity to change its syntax so it can accomodate such perversely anal-
  retentive needs as removing an operator from sight (even though you
  _still_ need apply).

| Many of the people who are attracted to Lisp in the first place don't
| like to clutter their programs with all these injections and coercions
| from one type to another.

  If they had anything approaching a usable intelligence, they would figure
  out how to write the macro I wrote, and I did not even have a problem
  with funcall to begin with, I was just so goddamn tired of the useless,
  incompetent whining from people who were so clueless they could not even
  write a little macro to get what they wanted.

| They're annoying and unnecessary.

  No, this is a conclusion about Common Lisp drawn from Scheme premises.
  Common Lisp is not a dialect of Scheme.  This is _precisely_ what this is
  all about.  You Scheme freaks are so full of yourself that you cannot
  even see that other people are _able_ to make other design choices than
  you have.  You think everything other people do is _wrong_, do you not?
  Some of you guys sure act like you have a one-bit right/wrong flag, and
  of course you do nothing wrong, so therefore what other people do must be
  _wrong_, since it is not what you do, and what you do is _right_.

  Common Lisp programmers do not regard this the same way you do.  _If_
  they do, they write something like the macro I wrote.  There _is_ no
  problem to a Common Lisp programmer -- a beginner would ask if it could
  be fixed and an experienced Common Lisp programmer would just do it.  It
  is _only_ a problem to Scheme freaks who have a grudge against Common
  Lisp and want to confirm their delusions of superiority to themselves.

| If you're a first- or second-order thinker, then you probably won't agree
| with this, and you'll be happy with a Lisp2.  If you're a higher-order
| thinker, you'd be happier with a Lisp1 if all else were equal.

  Lisp-1 and Lisp-2 have nothing whatsoever to do with this issue.  Even
  funcall is a non-issue.  What matters is probably what Kent Pitman has
  been hinting at: People who want a one-bit universe where purity and
  elegance and such follow very simple rules are much more attracted to
  functional programming languages _and_ Lisp-1.  You have the causality
  all wrong, here, and this is quite obvious: People are not _naturally_
  "higher-order thinkers", but there is much evidence to support a view
  that some people have a hard time dealing with "horizontal complexity"
  and much prefer "vertical complexity" on very small initial space.  These
  two types are fairly incompatible.  A vertical complexity guy will look
  at a horizontal complexity guy and think he is not superskilled in
  anything and therefore untrustworthy and useless (many academics fall
  into this trap), whereas a horizontal complexity guy who meets a vertical
  complexity will be stunned how little he knows about the world about some
  corner of which he has this astonishing amount of knowledge.

  Now, the most interesting thing happens is when they meet one of their
  own type: A vertical complexity guy will trust another and defer
  authority to him automatically in his "area", thinking (1) that he, too,
  has spent a lifetime in some incredibly small area, and (2) that you
  cannot go wrong if you study something long enough, especially not if
  some accredited university has granted him a degree.  However, those who
  master horizontal complexity much more easily, generally display an
  amazing amount of insight and knowledge in many areas, draw analogies
  from all kinds of areas, and they can communicate with others who master
  horizontal complexity with ease and can understand, not trust, those who
  have more knowledge in one area than another, because their knowledge is
  integrated into a system intended to mirror the world they experience.
  The vertical complexity guys have built their "system" from axioms and
  theorems that others have provided, before they may be able to provide
  their own deep insight into something that requires extremely specialized
  skills to appreciate.

  I suspect that functional programming (and Scheme) appeals to those who
  find that they master vertical complexity more easily and dynamic
  programming (and Common Lisp) appeals to those who find that they master
  horizontal complexity more easily.  However, this is _NOT_ (repeat: NOT)
  a one-bit flag in your personality.  But, *sigh*, what's the use?
  One-bit people are going to respond as if it is, as I have I created but
  two pigeonholes and want to stuff all of mankind into one of them, anyway.

 (defpackage temperature
   (:use "CL")
   (:shadow "T"))

 (in-package "TEMPERATURE")

 (defconstant true 'cl:t)

and you're all set.

Exactly because CL has packages, it's easy to redefine even reserved words.

  No, I said quite a bit more than that.  Separating function and variable
  values is a necessary condition, not a sufficient condition to not need
  hygienic macros.  Please return to the textbooks of whatever introductory
  course at your university or high school deals with argumentation and
  logic and LOOK UP THE DIFFERENCE BETWEEN NECESSARY AND SUFFICIENT,
  because you have truly not understood this and repeatedly make the
  mistake of conflating them.

  I recommend a book I came across by accident 12 years ago: The Art of
  Reasoning by David Kelley.  I have the first hardcover edition from 1988,
  but I see there is a third edition out in paperback:

http://www.amazon.com/exec/obidos/ASIN/0393972135

  There are probably lots and lots of books about thinking, but most of
  them seem to start with the assumption that you cannot think and thus
  have to learn it.  This book starts with assumption that you can think,
  you only need to train yourself and stay away from the mistakes.
  Thinking is an acquired skill, but most people have somehow gotten by.
  There is some value to not ignoring that fact.  However, many academics
  seem to have lost the ability to think clearly somewhere on the way to
  become extremely specialized in some arbitrarily complex field and they
  have certainly been rewarded with a highly characterized version of real
  thinking skills that is more about not feeling than about thinking.

| That's true only because
|
| 1) Global definitions are almost always functions.
| 2) Global data definitions have special names, by convention , and
|    people never shadow those.
| 3) People don't make local bindings in the function namespace.
|
| It's right that Lisp2 doesn't force you to follow those rules, but if you
| don't follow them, then you can't claim that CL macros are hygenic.

  Excuse me for knowing the Common Lisp language so well that I tend to
  forget that there are people out there with a strong desire _not_ to
  learn it before they shoot their mouths off.  Now is a good tiem for you
  to wonder what it means that I also talked about packages and try to
  figure out what a Common Lisp programmer must know in order to use his
  language.  In particular, a Common Lisp programmer has either read and
  understood 11.1.2.1.2 in the standard, or he has an implementation of
  Common Lisp (or a teacher) that enforces it.  In either case, he learns
  that he can trust that if he sees a function call to common-lisp:car, he
  _knows_ what it will do, with absolute certainty -- no need to check the
  lexical environment, no need to afraid someone clobbered it, no need to
  scrub off the non-hygienic crap that Scheme accretes because it has no
  package concept _and_ no distinction between functional and variable
  values so all the good variables names are taken.

  The reason Scheme needs hygienic macros is the same as the reason Scheme
  programmers do not call their arguments "list", but "lst".  We do not
  have _that_ problem in Common Lisp, either.  In short, Common Lisp is
  already a clean language, it does not need hygiene to clean up after its
  design decisions.