Aaron Hsu writes:
I am very leery of the cond-expand form, and I believe that it also fails to scale well. We have done little to fix the issues in using and making cond-expand useful. We have also ignored fundamentally more flexible and useful forms.
I say that cond-expand fails to scale well because it fails to provide a simple, program accessible method for extending and defining the set of constants that it recognizes.
Ah, thanks. Providing a run-time procedure that affects compile-time behavior is to create a phasing problem similar to those we have banished by excluding low-level macros and readtables that affect code. I'd hate to see phasing raise its ugly head in the small language.
The WG decided by unanimous consent to take no action on this ticket.
I don't know how to interpret the first two sentences. I assume the third sentence refers to the meta-cond proposal (essentially a cond using syntax-time variables and values), but the problem with that is that it depends heavily on what names are taken to be in scope at compile time, which is highly implementation-dependent. Because cond-expand recognizes only constants fixed by the implementation (plus which libraries are available for import, also basically fixed), it has no such phasing difficulties.