[Chicken-hackers] cond-expand and syntax-rules on Chicken 4

[Thomas Bushnell BSG]

I've noticed an oddity with chicken-4's implementation of syntax-rules,
which is inconsistent with the behavior of the Chicken 3 syntax-case
egg's version.

Consider the following source file:

(define-syntax foo
  (syntax-rules ()
    ((_)
     (cond-expand
      (compiling (display "in-mac compiling\n"))
      ((not compiling) (display "in-mac not compiling\n"))))))

(cond-expand
 (compiling (display "top-level compiling\n"))
 ((not compiling) (display "top-level not compiling\n")))

(foo)

When interpreted in Chicken 4 or Chicken 3, this produces the expected
output:
top-level not compiling
in-mac not compiling

When compiled with Chicken 3, using syntax-case, it produced the
expected:
top-level compiling
in-mac compiling

But when compiled with Chicken 4, it does this:
top-level compiling
in-mac not compiling

This is inconsistent with the behavior of syntax-rules as documented by
srfi 5, and has the effect of making it essentially impossible to have
macros which expand to cond-expand tests that check compile time.

Now, you might ask, why not put the cond-expand at top level and the
define-syntax within?  Well, alas, it happens that the define-syntax I'm
using has some substantial sub-macros inside a letrec-syntax outside the
cond-expand, so it's not at all convenient to invert it.

I can work around it by putting the cond-expand outside the syntax rules
to set a variable, and then testing that variable inside the
syntax-rules.  But still, this is a bug--or at least, a serious
difference in intepretation.  I think it's a clear bug.  It should be
possible to have syntax-rules expand to *any* form, including a
cond-expand form.  It is wrong for the evaluator to get in and evaluate
the cond-expand during macro-definition time.

Thomas