I thought (erroneously) that the problem I reported previously was that
somehow the feature set available to cond-expand inside a syntax-rules
template was the evaluation one and not the compilation one. No, the
situation is far worse.
The following code does not work:
(define-syntax foo
Thomas Bushnell BSG scripsit:
The following code does not work:
(define-syntax foo
(syntax-rules ()
((_)
(cond-expand
(chicken (display all good\n))
(foo)
Calling (features) shows that the feature name is chicken:, not
chicken. If you change the above to
On Nov 19, 2009, at 4:45 PM, Thomas Bushnell BSG wrote:
Ok, so this is too weird by half.
When I do (register-feature! 'foo), then the feature that is
registered
is foo:, despite what the actual manual says. And then, for some
baroque reason, cond-expand matches foo and foo: (even though
Kon Lovett scripsit:
'cond-expand' uses a function that ensures the tested symbol is a
keyword, so 'foo' '#:foo' are legal.
Fair enough. But in Chicken 4 syntax-rules macros, the non-keyword form
doesn't match, only the keyword form. That makes no sense. It's not
that cond-expand as a
On Nov 19, 2009, at 7:15 PM, John Cowan wrote:
Kon Lovett scripsit:
'cond-expand' uses a function that ensures the tested symbol is a
keyword, so 'foo' '#:foo' are legal.
Fair enough. But in Chicken 4 syntax-rules macros, the non-keyword
form
doesn't match, only the keyword form.
Thomas Bushnell BSG t...@becket.net writes:
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.
What does SRFI-5 have to do with
