Re: bug in syncase

[Dirk Herrmann]

Hello Neil,

> ;;; NIL-COND expressions have the form:
> ;;;
> ;;; (nil-cond COND VAL COND VAL ... ELSEVAL)

OK, done with that one.

> @fop is used to translate an Elisp application, and is complicated in
> two ways:
> 
> - When the application is translated, we don't know whether the CAR of
>   the application represents a function or a macro, and therefore
>   whether the application arguments need to be translated.
> 
> - The symbol in the CAR may need to be looked up recursively, for
>   defalias support.
> 
> The Scheme translation code translates (fn arg ...) to (@fop fn
> (transformer-macro arg ...)). Then, when (@fop ...) is memoized and
> evaluated,
> 
> - scm_m_atfop changes it to (address@hidden fnval (transformer-macro arg
>   ...))  if fnval is a function, or (fnval arg ...) if fnval is a
>   macro, where fnval is the function or macro obtained from looking up
>   fn's symbol function slot (recursively if needed)
> 
> - remaining evaluation of (address@hidden fnval (transformer-macro arg ...))
>   or (fnval arg ...) is done by the evaluator.

I have some questions about that one:  As you say, scm_m_atfop changes the
code in one of two ways, depending on the state of fnval at some point in
time.  Currently, this time is when the code is _executed_.  See the
following example:
  (define foo 1)
  (define (fn) <some code>)
  (define (bar) (if (= foo 2) (@fop fn (transformer-macro arg ...)))))
  (bar)
  (define foo 2)
  (defmacro fn args <some macro transformer>)
  (bar)
In the current implementation, the decision, how the @fop expression
should be changed, would be taken when foo was set to 2.  In contrast,
with my memoization phase I would like to perform the transformation
(including the expansion of the transformer-macro expression) at the point
where bar gets defined.

In other words:  Are there any statements about _when_ the expansion of
the @fop macro and the transformer-macro should happen?

Best regards,
Dirk Herrmann