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

> Due to hygiene
>
>    If a macro transformer inserts a binding for an identifier (variable
>    or keyword), the identifier will in effect be renamed throughout its
>    scope to avoid conflicts with other identifiers.
>
> the names bound by the require are renamed.

Thanks. How do I debug that in PLT? I tried switching to the Expander
language, but it doesn't seem to show me anything useful when
expanding sample expressions in the bottom window (I get
#<syntax...>). I seem to recall there was even a macro stepper for
PLT...

> SRFI-55 is the new kid on the block.
>
>    <http://srfi.schemers.org/srfi-55/mail-archive/msg00058.html>
>    <http://srfi.schemers.org/srfi-55/mail-archive/msg00006.html>

Those messages are from 2004. I tend to agree more with some of the
replies in those threads, such as those from Chicken's author...
SRFI-55 is a portable way to specify that a program depends on certain
SRFI's. It already works in Chicken, SISC and Guile. I don't see how
its availability could hurt users, and it seems it wouldn't clash with
PLT's design...

I'm sure you will be horrified, but from my point of view, it's like
this: why make me learn this new weird (require) syntax, when my I
just want to run my code in PLT?

> SRFI-0 is only a partial solution.
>     <http://srfi.schemers.org/srfi-0/mail-archive/msg00032.html>

But it already works across several implementations (Gambit, Chicken,
Bigloo, SISC, Guile) *today*. Again, I don't see how building it in
would hurt users (esthetical speculations aside).

Again, from a user's perspective, what can I add to my existing code
that will only be seen by PLT? With most other implementations, at
least I could conditionally load chicken-prelude.scm, sisc-prelude.scm
etc from a central prelude.scm. I hope you will at least see the
inconvenience of a missing cond-expand.

Best,
Dan Muresan