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

> Some of them will work, mostly. Compared to module-based
> there are technical limits (of the halting-problem variety) to how much
> DrScheme can support programs that are not in `module'.

OK. Do "inline" modules count, or do they have to be file-based
modules (inline ones can be redefined, I think)?

BTW, I didn't know DrScheme pushed statical analysis upto the limits
of computability -- sounds like I'll have many features to ooh and aah
over :)

> I think this is the only example where MzScheme lacks a popular
> feature
> simply because it's a poor solution that we reject on principle. (I can
> think of cases where we reject a language feature because it would
> other parts of the language, but that doesn't apply in this case.)
> Normally, we err on the side of providing too much.

I've only skimmed SRFI-0, as it didn't seem worth reading. I just know
that it lets me discriminate between underlying implementations, and I
know that this is a *very* legitimate need. If there's anything else
in SRFI-0 that bothers you, please ignore it, as everyone else, user
or implementor, does (correct me if I'm wrong).

There's also a timing issue. Yes, when/if everyone supports the R6RS
lib syntax, SRFI-0 will perhaps become obsolete. But when will that
happen? And how about old code that relies on SRFI-0?

Lastly, does the R6RS lib form actually let you distinguish between
implementations? Because there will always be implementation-specific
bugs to work around...

-- Dan