[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I don't have any strong objections to the basic idea here, except that
it makes the language bigger and more complicated (which nobody seems
to care much about anymore).

Some specific comments on the proposal:

* Presumably you want COMPILE-FILE to treat DEFINE-OPTIMIZER like DEFMACRO
  as far as compile-time side effects are concerned.

* Can DEFINE-OPTIMIZER be used to define an alternate expansion for a macro
  as well as a function call?

* I assume that the arglist to DEFINE-OPTIMIZER must be compatible with
  that of the corresponding function; for example, I couldn't do something

      (defun foo (x &rest more-args) ...)
      (define-optimizer foo (x y) ...)

  The proposal should explicitly state that the optimizer must be able
  to parse the argument list of every valid call to its associated function.

* I think there should be stronger wording to emphasize that neither the
  interpreter nor compiler is required to make use of transformations
  defined with DEFINE-OPTIMIZER.

* The example seems unnecessarily complicated.  I think something less
  hairy would serve to explain the construct better.

* I think there should be stronger wording to warn users about invalid
  "optimizations", and that the use of DEFINE-OPTIMIZER can lead to
  semantic differences between compiled and interpreted code.

* Can implementations provide some built-in optimizations for standard
  Common Lisp functions?  If I haven't defined any of my own optimizations,
  am I guaranteed that OPTIMIZE-EXPRESSION is the identity function on
  its argument?

* Is it legal for users to define optimizers for standard Common Lisp