(sublis (list (cons 'var var) (cons 'init init) (cons 'final final)
               (cons 'bodyform (cons 'progn body)))
   '(let ((var (1- init)))
      (while (>= final (setq var (1+ var))) bodyform)))

  yes.  don't bother.  many things in Emacs Lisp should not be replicated.
  instead, fix the Emacs sources and submit them as patches.

  um, I'm not sure this is a good idea, but here goes:

excl:   ;; compile and load this, do _not_ evaluate interpreted
(loop   ;; make the #\ reader fully ANSI CL compliant, ignore CLtL1.
  with readtables = (get-objects 11)
  for i from 1 to (aref readtables 0)
  for readtable = (aref readtables i) do
    (when (readtable-dispatch-tables readtable)
      (set-dispatch-macro-character #\# #\\
        (named-function sharp-backslash
          (lambda (stream backslash font)
            (declare (ignore font))
            (stream-unread-char backslash stream)
            (let* ((charstring (read-extended-token stream)))
              (unless *read-suppress*
                (or (if (= (length charstring) 1)
                      (char charstring 0)
                      (name-char charstring))
                    (internal-reader-error
                     stream "Meaningless character name ~A"
                     (string-upcase charstring)))))))
        readtable)))

  this is deliberately Allegro CL-specific and hopefully won't work
  anywhere else.  unsupported, copyrighted, no warranties kind of stuff,
  based on my understanding of source code licensed to supported customers,
  but not derived from which, etc, legal blah blah blah, sue Bill Gates if
  you have problems, and indemnify everybody else, OK?  cancel?  <click>

  for this particular case, it would, but the byte code interpreter calls
  out to functions all the time, and you would need to implement almost
  everything anyway.  the byte code is also more incompatible between the
  various versions of Emacs than the source is.  not that it isn't a good
  idea, but it would probably cause a lot more work than you think to get
  it right everywhere.

    (defmacro forever (&rest body)
      `(do () (nil) ,@body))

you have to write

    (defmacro forever (&rest body)        ; old-style Emacs Lisp
      (` (do () (nil) (,@ body)))

Clearly, this rapidly becomes incomprehensible as the complexity of the
backquoted form rises.

Modern Emacs Lisp readers have horrific kluges to recognise old-style
backquoting; this also means that certain (admittedly obscure) usages of
backquote will fail.

If I recall correctly, the ANSI CL spec suggests (but does not require)
that implementations of the backquote reader try to be compatible with
Scheme and other dialects, which provide macros (as opposed to reader
macros) for doing some of the same things as CL backquote does.

For example, there should be macros named QUASIQUOTE, UNQUOTE and
UNQUOTE-SPLICING.  (If one wanted to provide similar utilities for other
CL backquoting features that are not part of Scheme, one would also
define something like "unquote-splicing!" and "quasivector".)

I don't know how many CL implementations do this, but if they support
anything like this (even with different names,) then it should be pretty
easy to support elisp quasiquoting macros within CL.

It is not clear to me whether one could then get away with either of:
 1. globally replacing "(` " (with space) to "(quasiquote ",
    "(,@ " => "(unquote-splicing ", etc.
 2. Hacking the ` reader to return the symbol QUASIQUOTE if the next
character is
    a space, and similarly for , and ,@.  This would allows .el files to
be used
    directly, without modification.  However, it might screw up .lisp
files, so
    arrangements would have to made such that the modified readtable
would be used
    only on .el files.
Both of these depend on the assumption that "old style elisp
backquoting" relied on whitespace to terminate the symbols named "`",
"," and ",@".  

If this concept is sound, I can donate some untested code to the cause.
I have code for the next version of Eclipse that implements QUASIQUOTE,
etc., macros, and coordinates them with the backquote reader macros.
The code is about 4 screen fulls and is loosely based on appendix C in
CLtL2.  Contact me if you want it.  Here's an overview:

;;; We process quasiquote forms at macroexpansion time, and backquote
;;; forms at read time.  In either case, processing involves
;;; simplifiying the forms and transforming them to bq-xxx forms.  The
;;; bq-xxx macros expand into xxx, but are recognized by the
;;; pretty-printer so that they can be printed using backquote
;;; characters.  They also keep the simplifier from mistakenly
;;; simplifying user code.

The syntax of Backquote is about as ugly as one can imagine.
Unfortunately, backquote is almost always used when
defining macros.  And with the macro being one of the key
strengths of lisp, we have the situation where a key strength
of lisp uses one of the most bizarre and ugly syntactic constructs
in the language.  At least parenthesis have a form of beauty
and functionality, but backquote is just plain ugly and bizzare.

So how about some suggestions on something different,
something better.  How about a straw man:
Use [] to replace , and {} to replace ,@
i.e.  `(zap ,foo ,@bar)   ==> `(zap [foo] {bar})

Assuming your suggestion was serious (I've got this funny feeling I may have
missed the joke in your post), why do you think the current syntax is ugly?

where else do you find the comma attached to the *front* of anything?

i suppose you get used to it, but it is rather jarring to have your
normal sense of where to put commas completely turned on its head.

    JK> i suppose you get used to it, but it is rather jarring to have
    JK> your normal sense of where to put commas completely turned on
    JK> its head.

How is this different than '+' in prefix?
You get used to it in about a few hours, in my experience.
I may be biased though, I already had decided that I loved lisp
when I started using backquote and comma.  

The other problem I have with this is that this would add more
parentheses to the program; as the most often heard complaint from
newcomers is that all the parens make the language unreadable, adding
more of them would be unlikely to help.

I find that I actually prefer Lisp's style of using no explicit end
delimiter in quote etc.: saves me from all the problems with missing or
misplaced end delimiters, the whitespace or parens ending the form are
quite sufficient for my taste as end indicators.

I prefer the current backquote to your suggestion, I'd rather save the
[]{} for the user for any extension languages etc.

  this isn't quite true.  the new-style backquoting is returned as
  old-style function calls with funny function names.

(car (read-from-string "`(a ,b ,@c)")) => (\` (a (\, b) (\,@ c)))

  (the two values are returned as a cons.)  moreover, ` is a macro:

(symbol-function '\`) => (macro . #<lambda (arg)>)

  this macro is not very well-written and frequently gets seriously
  confused.

  what do you mean "comma"?  don't you see it's a low quote?

  basically "use it, don't change it, don't redistribute it."

  it's much better for all of us that this is fixed in the actual sources.

(and what about colons on the front of keywords...)

  it doesn't appear that you want to use Common Lisp at all, but it also
  doesn't appear that you have any gripes more fundamental than syntactic
  aesthetics.  what gives?  this is a part of the language you can change
  at will, but there simply is no need to do this in Common Lisp.

  speaking of which, I explained to the British guy sitting next to me on a
  recent transatlantic flight that I worked with Common Lisp.  he in turn
  talked about his great hobby: ornithology, where "common" is a synonym
  for "garden", as in "garden variety".  he thought it would have better
  acceptance if it was called "Garden Lisp".  feel free to use it, Kelly.