Re: [Chicken-hackers] cond-expand and macros

2009-11-20 Thread Thomas Bushnell BSG
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 example and description in the
manual.

 '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.)

So the bug is more or less that the self-evaluating nature of keywords
doesn't work in the meta-environment for macro expansion, I assume.  
(Certainly that it goes differently in Chicken3+syntax-case is no
mystery, since the old syntax-case egg needed to provide its own
implementation of cond-expand anyway.)

Thomas




___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers


Re: [Chicken-hackers] cond-expand and macros

2009-11-20 Thread Kon Lovett


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, one might have thought
they were ordinary symbols given every example and description in the
manual.


Please submit a bug report.




'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.)


So the bug is more or less that the self-evaluating nature of keywords
doesn't work in the meta-environment for macro expansion, I assume.


No, they are ordinary symbols (assuming the keyword read syntax is not  
present). The proffered symbol is converted to a keyword before  
comparison with the set of features. But this is performed by a  
procedure not the macro expander.


The self-evaluating nature of keywords works in macros AFAIK.


(Certainly that it goes differently in Chicken3+syntax-case is no
mystery, since the old syntax-case egg needed to provide its own
implementation of cond-expand anyway.)

Thomas




Best Wishes,
Kon




___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers


Re: [Chicken-hackers] cond-expand and macros

2009-11-19 Thread John Cowan
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.

-- 
My corporate data's a mess! John Cowan
It's all semi-structured, no less.  http://www.ccil.org/~cowan
But I'll be carefreeco...@ccil.org
Using XSLT
On an XML DBMS.


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers


Re: [Chicken-hackers] cond-expand and macros

2009-11-19 Thread Kon Lovett


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


Re: [Chicken-hackers] cond-expand and macros

2009-11-19 Thread John Cowan
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 whole isn't being recognized, because it is;
it throws an error because there is no match.

-- 
The serene chaos that is Courage, and the phenomenon   co...@ccil.org
of Unopened Consciousness have been known to theJohn Cowan
Great World eons longer than Extaboulism.
Why is that? the woman inquired.
Because I just made that word up, the Master said wisely.
--Kehlog Albran, The Profit http://www.ccil.org/~cowan


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers


Re: [Chicken-hackers] cond-expand and macros

2009-11-19 Thread Kon Lovett


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.  That makes no sense.  It's not
that cond-expand as a whole isn't being recognized, because it is;
it throws an error because there is no match.


My hypothesis (I didn't check) is the non-keyword symbol is run thru a  
hygiene regimen; keywords cannot be identifiers so exempt. Maybe:


(syntax-rules (foo)
((_ ?x ?y)
(cond-expand
(foo ...

might do something useful.



--
The serene chaos that is Courage, and the phenomenon   co...@ccil.org
of Unopened Consciousness have been known to theJohn Cowan
Great World eons longer than Extaboulism.
Why is that? the woman inquired.
Because I just made that word up, the Master said wisely.
   --Kehlog Albran, The Profit http://www.ccil.org/~cowan


Best Wishes,
Kon




___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers