[plt-scheme] (require... ) expanded from a macro

> No, you couldn't, at least not over time.  "plt" doesn't correspond to
> any language features you could rely on, as it's a moving target.

I don't think the (require) syntax  is going to change anytime soon,
or the module names, or any of the things that I *actually* need at
the cond-expand level.

And if the API does change that drastically, then perhaps the right
solution is to provide features that can be checked at cond-expand
level.

> (The C people figured this out 10 years ago.)

Really? In C I can keep multiple implementation variants in one file
(or multiple conditionally-included "modules"). I can pass the
compiler some flag from the Makefile to determine if I'm in gcc or
Visual C, and I can use #if and friends in the source. Or I could even
depend on builtin compiler macros to tell which implementation I'm
under.

What is the PLT equivalent, again?

Now, imagine that some C compiler called #ifdef %%ifdef, some other
compiler called it #%if_expand, and some other didn't offer it at all.
And why? Because #ifdef was "poorly designed". How is it poorly
designed? It's not complex enough. And what will be the long-term
solution? The C2010 standard will provide a "smart" #if system, and
checking the underlying implementation will become unnecessary (yeah
right).

I think that's the closest parallel to the anti-cond-expand camp.

By the way, being able to create new languages really saved the day
for me. I just added the things I needed (cond-expand, most
importantly) to a new language module. As a result:

* I'm not maintaining two sets of sources

* I don't have to get into any of these nice "the right thing,
practicallity be damned" arguments anymore

OK, sorry for the rant, I'm just frustrated. It's just that life is
short, and I burried a day or two just to figure these PLT
peculiarities out (not to mention the time of the helpful souls on
this list who helped me along).

Best,
Dan