Re: bug in syncase

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:

    Dirk> Yes, I could need some help: What are the macros nil-cond
    Dirk> and @fop used for, and how are their macro transformers
    Dirk> supposed to work?

nil-cond's macro transformer just replaces nil-cond by address@hidden
nil-cond is just a simplified cond, described in
lang/elisp/primitives/syntax.scm as:

;;; NIL-COND expressions have the form:
;;;
;;; (nil-cond COND VAL COND VAL ... ELSEVAL)
;;;
;;; The CONDs are evaluated in order until one of them returns true
;;; (in the Elisp sense, so not including empty lists).  If a COND
;;; returns true, its corresponding VAL is evaluated and returned,
;;; except if that VAL is the unspecified value, in which case the
;;; result of evaluating the COND is returned.  If none of the COND's
;;; returns true, ELSEVAL is evaluated and its value returned.

@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.

Does this help?  Let me know if you need any more.

        Neil