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 there is
no "foo" feature registered, since it's actually foo:) and then,
inside
the context of a syntax-rules, suddenly cond-expand *doesn't* match
foo,
though it still matches foo:.
Can I cry foul? Why doesn't register-feature! simply register the
feature specified without this on-again-off-again colon magic? What
is
the point of adding a colon in the first place to the symbol name?
Why
is it magically removed again sometimes?
Features are converted to keywords. The colon suffix is just the
default read/print form; #:keyword is the context-independent form.
'cond-expand' uses a function that ensures the tested symbol is a
keyword, so 'foo' & '#:foo' are legal.
That the expansion-environment of a 'syntax-rules' transformer doesn't
recognize 'cond-expand' is a different problem. (Note that 'syntax-
rules' in Chicken 3 is not a core expander.)
Thomas
On Thu, 2009-11-19 at 19:27 -0500, John Cowan wrote:
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 reference chicken:, all is
well.
This is not backward compatible and is still probably a bug, but at
least it's a simple bug.
On the other hand, (cond-expand (chicken (display "all good\n")))
does
output "all good" right away.
_______________________________________________
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Best Wishes,
Kon
_______________________________________________
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers