[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug in syncase
Re: bug in syncase
Thu, 21 Nov 2002 18:53:51 +0100 (CET)
> ;;; 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
> - 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
(define foo 1)
(define (fn) <some code>)
(define (bar) (if (= foo 2) (@fop fn (transformer-macro arg ...)))))
(define foo 2)
(defmacro fn args <some macro transformer>)
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?