by contrast, dynamic-wind implements "remember to save and
restore this state each time i'm working on a certain project"
mostly people streamline their activities to avoid state changes,
so they don't find needs to articulate descriptions of state changes
because they work to make them not happen.  i'm talking about the
real world, not computers. projects and task interleaving do occur
in the real world but are rarer than just projects un-interleaved.

my comment was NOT meant to say that other operators aren't useful.
just that i think unwind-protect is primitively important even to
non-programmers in routine and very mundane tasks in ways that dynamic
wind is not.  i think unwind-protect is "conceptually more primitive"
(in that most people have the concept before learning how to
articulate computerized computation) than dynamic wind (where i think
many people don't have the concept until taught to think tha way).
i'm not making a statement about the relative usefulness of these
operators per se.  i'm saying that a decision by a language to deny
the ability to express a "conceptually primitive" concept is more
telling than a decision to deny a "learned" concept.

just my opinion.  you're welcome to disagree.  (i've never heard
anyone agree with me, actually.  it's a pretty odd "test" for a
language, i guess.  but it's one that has held up for me over time.)

(What's this doing in comp.lang.lisp?)

If you're not planning on resuming, you can simply provide a a function
that signals an error as the before-thunk to dynamic-wind, and you have
something equivalent to unwind-protect.

  because the byte-code interpretation machinery must add _some_ overhead
  to the execution, and the more byte-code, the slower it runs, as in
  wholly user-defined functions.  the more stuff is implemented in the real
  implementation language, the faster it runs.  this skews the way people
  look at performance, and which features they'll use.  when abstraction is
  expensive, people don't do it.  when abstraction is cheaper than not
  doing it, the benefits become more obvious.

| I should have just made up my mind before being confused with the facts.

  that's always good advice when the world is too complex to answer one's
  questions simply.  (I think it helps to understand complexity and then go
  back and decide to ignore some of it, but far too many frown at the
  complexity of the world and actively denounce tools and languages and
  techniques intended to deal with it.)

| I have to wonder how much of Common Lisp must be implemented as native,
| and how much can be implemented in Common Lisp.

  this depends on how you implement your "native" functions.  it's possible
  to write a proto-Lisp that a simple compiler compiles to machine code and
  then implement enough Common Lisp in proto-Lisp to be able to build a new
  system entirely in Common Lisp.  (this proto-Lisp can in fact be another
  language entirely, but then it's _more_ work to build the compiler.)

| Paul Graham says in his book that one of the features of Common Lisp is
| that it can extend itself.  I am only a little way into the book, but I
| like what I have seen so far.  I just wish I had a free ANSI Common Lisp
| implementation on NT that I could play with his examples on.  Any
| recommendations?

  why do you need NT?  it takes less effort to install Linux and run
  Allegro CL 5.0 Trial Edition (an uncrippled version recently released)
  than it takes to find something free and high quality under NT.

When using the word conceptually, though, I was
talking about how human beings describe processes in the real world.
My point was that humans don't have (that they speak about) stacks,
so when they do context switches, they don't do (that they speak of)
this operation.  Consequently, linguistically, they do not use these
terms "primitively" (without training to do so).  The world is indeed
prone to having re-entrant processes.  People might read a book and
watch TV, for example.  But where state changes are required, people
try (i observe informally) to avoid having to do the state change
(see the literature on "practice effects" and think about the kinds of
optimizations people make to operations).  if i use reading glasses
to read, i don't want to read and watch TV at the same time because
i have to keep putting on and removing my glasses.  i avoid that.
or i invent bifocals so that i don't have to change them in between.
but either way, i avoid the need to linguistically discuss the state
change.  human linguistics is driven by experience, not vice versa.
you can try to teach people terms they have no experience about in order
to broaden their horizons, but in my opinion all but the intellectual
class will resent you for it.  all just my armchair observations
and conclusions-of-the-day.  feel free to disagree.  i may be wrong
about the data or wrong about the conclusions that it's not linguistic,
but those are both premises to my real claim which is that if
you believe (as i do, right or wrong) that dynamic-wind is not
"conceptually primitive", then you understand why it is that i
think it's not as fundamental a "tell" to the thoughtfulness
of the language in other regards.

as to the usefulness of dynamic-wind, i'm not saying it's unimportant.
ever since i heard about it in 1981, i've repeatedly reminded people
of its existence and advocated its adoption on occasion.  it doesn't
just trouble me that it's absent.  it also troubles me that "places"
aren't just as good as "variables" in special binding.  if you believe
in special binding at all, and i do, it should seem clear that it's
about "the process of dynamically instantiating within a task that is
possibly interleaved with other tasks for which the dynamic instantiation
has not been done" and that doing it only for symbols is a hack
reminiiscent of maclisp sublis, which as i recall (might be wrong)
only allowed you to sublis for symbols because it was possible to
attach a property to symbols (and not to all objects) allowing
constant (or almost that) time access to the substitution object.
So instead of O(m*n) performance [a size m object and n replacements]
you'd get O(m).  But at the price that you couldn't sublis other
objects at all.  If they'd just fallen out to using alists or
hash tables or some such in the other case, it could have been defined
on anything.  (Some have made the same criticism about GET and
property lists.)

optimization is important, but it shouldn't come at the price of not
allowing the unoptimized cases.  there may be ways to optimize other
cases in the future and the language should plan for that, leaving it
to users to make a judgment about which features they exercise at what
point in time based on their market needs.

trash...@david-steuber.com (David Steuber "The Interloper") writes:

< Paul Graham says in his book that one of the features of Common Lisp
< is that it can extend itself.  I am only a little way into the book,
< but I like what I have seen so far.  I just wish I had a free ANSI
< Common Lisp implementation on NT that I could play with his examples
< on.  Any recommendations?

CLISP will run under DOS and windows. Also there is LispWorks for
windows (I think it will work with the New Technology - as windows
always seems to take an aggresive stance to be backwards compatibe :)

I have no url for LispWorks (sorry) maybe someone will shout it out;
a search engine will certainly pick it up.

                 PRINCIPLES OF PROGRAMMING LANGUAGES:
                        COMMON LISP VS. SCHEME

           Gary T. Leavens, Department of Computer Science,
           Iowa State University, Ames, Iowa 50011-1040 USA
                        leav...@cs.iastate.edu
                     $Date: 1995/09/23 18:38:01 $

The table below highlights the important differences between
Common Lisp and Scheme for those that know a more standard
Lisp dialect.  Only the differences are highlighted here,
there are many more similarities.

Common Lisp                     Scheme
-------------------------------------------------------
()      ; eq to nil             ()
nil                             #f
t                               #t

(eq x y)                        (eq? x y)
(equal x y)                     (equal? x y)

(atom x)                        (not (pair? x))
(consp x)                       (pair? x)
(null x)                        (null? x)
(symbolp x)                     (symbol? x)
(zerop x)                       (zero? x)

(setf (car x) y)                (set-car! x y)
(setf (cdr x) y)                (set-cdr! x y)

(mapcar #'f l)                  (map f l)
(map 'list #'f l)               (map f l)

(mapcar #'(lambda (x) (g x)) l) (map (lambda (x) (g x)) l)

#'(lambda (x) y)                (lambda (x) y)

(setq var y)                    (set! var y)
(setf var y)                    (set! var y)

(cond                           (cond
  ((null x) 0)                    ((null? x) 0)
  ((eq x y) (f x))                ((eq? x y) (f x))
  (t (g y)))                      (else (g y)))

(defun square (x)               (define (square x)
  (* x x))                        (* x x))
                                ; or
                                (define square (lambda (x) (* x x)))

(funcall (g f) x)               ((g f) x)

(defun compose (f g)            (define (compose f g)
  #'(lambda (x)                    (lambda (x)
      (funcall f                      (f (g x))))
        (funcall g x))))

Acknowledgments

Thanks to Erik Naggum and Richard Gabriel for correcting my ancient
LISP accent.  Of course any errors are not their responsibility but mine.

Kent M Pitman wrote in a message ...
[comparison about dynamic-wind elided]

I think I agree with Barry (barmar) that it is pretty easy to view
unwind protect as a dynamic-wind with an empty entry thunk (in
most cases).

I was just concerned with the the syllogism:

1.  Languages without unwind-protect are not well thought out.
2.  Scheme doesn't have unwind protect.

I know you disagree with much of what the Scheme people say, but
you can't say they don't think about what they are doing.

(defun car (x)
  (car x))

and then depend on the compiler to generate the appropriate code.  I don't
really think these trivial cases count.  Nor would LAP.  I'm not sure
whether to count "subprimitives", e.g. something like:

(defun car (x)
  (case (system:%typecode x)
    ((1) (system:%memory-ref x 0)) ; cons
    (t (error ...))))
(defun car (x)
  (case (system:%typecode x)
    ((1) (system:%memory-ref x 1)) ; cons
    (t (error ...))))

(defmacro lambda ((&rest arglist) &body body)
  `#'(lambda (,@arglist) ,@body))

But it's probably good to have it in the table, since you're likely to see
it in old code (and new code by people who want to be portable to old
environments, don't like the macro, or just can't break the habit).

It would probably be a good idea to show an example of #'<function-name> in
the table.  Perhaps after the definitions of compose, you could demonstrate
this in a use:

CL:

(defun *-+ (x y)
  (funcall (compose #'* #'+) x y)

Scheme:

(define (*-+ x y)
  ((compose * +) x y))

(defun car (list) "Returns the 1st object in a list." (car list))

  BTW, shouldn't this last one be cdr?

(Yes, of course I know these are trivial errors.)

Then again, I also really like Smalltalk and SML.

(defun my-cadr (ls)             (define my-cadr (ls)
  (funcall                        ((compose car cdr)
   (compose #'car #'cdr)            ls))
   ls))

I thought that composing two functions that are usually considered binary
would be confusing.

Thanks for the help,

        Gary Leavens

frank_adr...@firstdatabank.com (W)
fra...@europa.com (H)

Regs, Pierre

Footnotes:
[1]  free as in "no money" for personal use, _not_ free as in GPL'd
software.

CL:

(defun list-cons (element list)
  (list element list))

Scheme:

(define (list-cons element lst)
  (list element lst))

You see it even in code that doesn't use the conflicting function,
such as

 (define (adjoin element lst)
   (if (member? element lst) lst (cons element lst)))

I saw a special on TV once about Bitstream, the font company, in which
someone pointed out that font design is not really about the design of
letters.  It's about the design of words.  The letters are right when
if you compose them, the words look good.  By analogy, I believe
a language is right if, when you compose sentences in it, the sentences
look good.  I tend to believe a language that doesn't offer me a way
to say the unwind-protect thing leaves me looking stupid when I want to
express this concept, and I personally feel undervalued by languages
that do not accomodate my need in this regard.

It's just my personal judgment.  Your mileage may, of course, vary.