Some time ago, I wrote these, and put them in my customized lisp,
  but I have not used them much since then.

(defun letf-bindings (bindings environment)
  (let ((savers ())
        (setters ())
        (restorers ()))
    (loop
     for (place values-form) in bindings do
      (multiple-value-bind (vars vals stores setter getter)
          (get-setf-expansion place environment)
        (let ((save (gensym))
              (store (first stores))
              (multiple-values (rest stores)))
          (setf savers (nconc (nreverse (mapcar #'list vars vals)) savers))
          (push `(,save ,(if multiple-values
                           `(multiple-value-list ,getter)
                           getter))
                savers)
          (push (if multiple-values
                  `(multiple-value-bind ,stores ,values-form ,setter)
                  `(let ((,store ,values-form)) ,setter))
                setters)
          (push (if multiple-values
                  `(multiple-value-bind ,stores (values-list ,save) ,setter)
                  `(let ((,store ,save)) ,setter))
                restorers))))
    (values (nreverse savers) (nreverse setters) (nreverse restorers))))

(defmacro letf* (bindings &body body &environment environment)
  "Simulate serial shallow binding of places in BINDINGS around BODY."
  (if bindings
    (multiple-value-bind (savers setters restorers)
        (letf-bindings (list (first bindings)) environment)
      `(let* (,@savers)
         ,@setters
         (unwind-protect
             ,`(letf* ,(rest bindings) ,@body)
           ,@restorers)))
    `(progn ,@body)))

(defmacro letf (bindings &body body &environment environment)
  "Simulate parallell shallow binding of places in BINDINGS around BODY."
  (if bindings
    (multiple-value-bind (savers setters restorers)
        (letf-bindings bindings environment)
      `(let* (,@savers)
         ,@setters
         (unwind-protect
             (progn ,@body)
           ,@restorers)))
    `(progn ,@body)))

I suggest that you move the setter forms to within the unwind-protect:

(defmacro letf (bindings &body body &environment environment)
  "Simulate parallel shallow binding of places in BINDINGS around BODY."
  (if bindings
    (multiple-value-bind (savers setters restorers)
        (letf-bindings bindings environment)
      `(let* (,@savers)
         ;; ,@setters  <-- remove this line
         (unwind-protect
             (progn      
               ,@setters  ;; <--- insert it here
               ,@body)
           ,@restorers)))
    `(progn ,@body)))

  Doing so gives you nothing but a false sense of improved security.

| The problem with LETF (as written) is that it will not work in a
| multitasking environment, so be careful with it.

  It will work exactly as well as, and no better than, doing the same
  settings "manually", i.e., without the macro.  This is intentional.
  The problem is not with letf, but with setting such places.  This is
  actually very important to understand: letf does not make it worse,
  but it also cannot protect you from the problem.

Suppose we have a LETF like this:
  (letf (((xyzzy y) 22)
         ((car (fun x)) (foobar a b c)))
     (do-something))

Here are the failure modes:
  1.  A `value' cannot be computed.  For instance, (foobar a b c)
      throws an error.  Since all values are computed before any
      binding, these forms do not need to be protected.

  2.  A `place' cannot be computed.  For instance, (fun x) throws an
      error.  Since all places are computed before any binding, these
      forms do not need to be protected.

  3.  The `access' cannot be computed.  For instance, (xyzzy y) throws
      an error, or (fun x) does not return a cons.  Since all values
      are computed before any binding, these forms do not need to be
      protected.

  4.  The `store' cannot be computed.  For instance, the implied
      rplaca or (setf xyzzy) throws an error.  Should one of these
      forms throw an error, that particular binding will not have
      happened, but prior bindings will.

  5.  The `store' is not idempotent.  For instance, (setf xyzzy) acts
      differently each time it is called.  In this case you are
      probably hosed.

Now the original macro computes the values, the places, the accesses
and the first set of stores outside the unwind protect.  Should some
of the stores run, but one throws out, the stores that have already
been done will not be undone since we are outside the unwind-protect.

However, by placing the stores inside the unwind-protect, should one
of the stores error out, we will run the cleanup forms.  Of course the
cleanup forms run the same stores, so it is virtually certain that the
cleanup forms will error out as well, *but probably at the same form*.

This is the key.  Most of the SETF store functions will be no more
complicated than RPLACA (in a typical case).  So it is highly likely
that the ones able to run to completion upon entry they will be able
to run to completion on exit.

We are also relying on the store functions being run in the same order
when binding and unbinding.  If the order were reversed, for example,
the above argument doesn't hold.

Also consider manually aborting out of the first set of store
functions (I think a more likely scenario than erroring out).  Even if
only some of the modifications run, and all of the `unmodifications'
run, it is presumably ok to store the original value `on top of
itself'.

So although moving the store functions to inside the unwind-protect is
no panacea, it will likely make your life easier.

they don't seem to deal with declarations properly.  This can be
particularly important in LET and LET* forms.  Is it a finite amount of
work to get the basic declarations to work with LETF(*) as defined in
the previous post?

  The places they are supposed to be used on are not variables that
  will be used in the body, so declarations are less relevant than in
  most other places.  It is of course a finite amount of work to make
  declarations work: Wrap a let form around the body instead progn, as
  always when you want declarations to work.

It is certainly plausible that at some time in the past you
experimented with using LOCALLY, found it didn't do what you wanted,
and therefore made the decision not to _start_ using it.

Be that as it may, I was indulging in idle speculation.  But my
statement was not devoid of value:  there is a bug in how Allegro CL
handles LOCALLY.

Granted, the compiler is always free to ignore declarations (except
for special ones, of course), but given that the compiler does produce
optimized code when the declarations follow a LET statement, and fails
to do so when the declarations follow a LOCALLY, it is fair to say
that LOCALLY isn't working.

(in-package "USER")

(eval-when (:compile-toplevel :load-toplevel :execute)
  (deftype array-index ()
    `(INTEGER 0 ,array-dimension-limit))
  )

(defun test-one (y x)
  (check-type x array-index)
  (check-type y (simple-array t (*)))
  (locally (declare (type array-index x)
                    (type (simple-array t (*)) y)
                    (optimize (speed 3) (safety 1))
                    #+allegro (:explain :calls :types))
    (aref y x)))

;Examining a call to AREF with arguments:
;  symeval Y type T
;  symeval X type T
; which returns a value of type T
;Generating a non-inline NON-SELF tail jump to AREF

;;; 157: 8b c3       movl       eax,ebx
;;; 159: 8b 55 e4    movl       edx,[ebp-28]    ; X
;;; 162: c9          leave
;;; 163: 8b 5e 42    movl       ebx,[esi+66]    ; AREF
;;; 166: ff 67 27    jmp        *[edi+39]       ; SYS::TRAMP-TWO

(defun test-two (y x)
  (check-type x array-index)
  (check-type y (simple-array t (*)))
  (let ((x x)
        (y y))
    (declare (type array-index x)
             (type (simple-array t (*)) y)
             (optimize (speed 3) (safety 1))
             #+allegro (:explain :calls :types))
    (aref y x)))

;Examining a call to AREF with arguments:
;  symeval Y type (SIMPLE-ARRAY T (*))
;  symeval X type (INTEGER 0 16777216)
; which returns a value of type T

What the compiler fails to do is to process _free_ type declarations.
Recall that a "free" declaration is one concerning about a binding made
at some contour interior to the one that established that binding.  So:

(defun foo (x n)
  (declare (optimize (speed 3) (safety 0)))  
  (let ()
    (declare (type simple-string x))
    (char x n)))

(defun foo (x n)
  (declare (optimize (speed 3) (safety 0)))  
  (locally ()
    (declare (type simple-string x))
    (char x n)))

These forms are treated identically, and neither will be optimized the
way the programmer clearly intends.  It is only free type declarations
that are ignored (other than syntax checking, etc.) and OPTIMIZE,
SPECIAL, and other free declaratione are processed as one would expect.

The only difference between a LOCALLY and a LET with no bindings is that
the former when used at top-level passes the quality of top-level-ness to
its body.  This is as required by the ANS.

  _That_ is just Wrong, too!  Argh!

Thanks,

/Jon

  This is a completely bogus question.  Pull yourself together and
  _think_ carefully about what you request from the standard, and to
  what level of redundant detail it had to go if it were able to
  answer your question.

/Jon

A correct type declaration never has any semantic effect on a correct
program.  (Obvious exception: A slot type declaration affects what is
returned by slot-definition-type, but that is visible only using the
MOP.)  If you can tell whether the implementation did or did not
observe a type declaration, using only behavior mandated in the ANS,
then your program and/or its declarations were incorrect and violated
the standard.

I think the whole thing boils down to my thinking
that the (rather
extensive) exchanges by folks I consider
knowledgeable indicated that
there was something more to all of this than that
ACL simply took
advantage of the rule in one context and not
another.  That appears to
have been the major error on my part.

/Jon

--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478,
617.484.3383
"Nightmares - Ha!  The way my life's been going
lately,
 Who'd notice?"  -- Londo Mollari

Regs, Pierre.

/Jon