On Thu, 2009-11-19 at 18:33 -0800, Kon Lovett wrote:
Features are converted to keywords. The colon suffix is just the
default read/print form; #:keyword is the context-independent form.
The manual needs to document this; right now, one might have thought
they were ordinary symbols given every
On Nov 20, 2009, at 10:05 AM, Thomas Bushnell BSG wrote:
On Thu, 2009-11-19 at 18:33 -0800, Kon Lovett wrote:
Features are converted to keywords. The colon suffix is just the
default read/print form; #:keyword is the context-independent form.
The manual needs to document this; right now,
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.
