[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with rationale & design
On Mon, 21 Jun 2004, Felix Winkelmann wrote:
> campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> > On Sat, 19 Jun 2004, felix wrote:
> > Sorry, but this is just an empty arguemnt about your personal taste,
> > and it has absolutely no place in this argument.
> Any argument is in the end about taste. Ease of use can be considered
> a pure taste issue. If you want to push me into this corner, then, yes,
> SRFI-55 reflects my personal taste, just as SRFI-7 does yours.
> > Yes, SRFI 55 can't be implemented without restructuring a great deal of
> > Scheme48's compiler. I consider only one implementation's module
> > system because it is the only one that I know of that has the property
> > that module data can't be embedded into source data. A quick check
> > shows that RScheme's module system _seems_ to have this property as
> > well, though I'm not _entirely_ sure. But it's irrelevant that I can
> > think of no others;
> That's unfortunate. I think this makes both of them harder to use
> than necessary. Yet, why should other implementations artifically
> restrict themselves, even if they allow for more convenience?
> > Again, this is moving to the issue of taste, which should _not_ be in
> > this discussion as long as technical merit is at issue.
> I see ease of use as a form of technical merit.
> > It's amazing to see how the fact that Scheme48's & RScheme's module
> > systems can't implement REQUIRE is stubbornly ignored! I am _not_
> > saying that REQUIRE-like mechanisms are inherently incompatible with
> > _all_ module systems, but that they _can_ be incompatible with _some_
> > module systems, whereas a separate configuration language can _always_
> > be compatible with module systems.
This property in RScheme's module system arises from the design goal of
permitting complete control over the symbols bound in a module's
environment, necessitating a mechanism that lives outside of the module's
This is not an architectural limitation, just a useful design goal. In
RScheme, it is perfectly possible to implement a form such as that of
SRFI-55's require-extension, and even make it available in the default
(BTW, in the early stages of work on SRFI-0, when it seemed to be
conceptually compatible, RScheme *did* load (if necessary) and import
modules on demand to satisfy cond-expand expressions. I've since turned
off that feature. Just FYI, it'd be just as easy, for RScheme, for
SRFI-55 to simply state that import-on-test behavior is acceptable, as to
add a new form which explicity does so.)
-- Donovan Kolbly ( d.kolbly@xxxxxxxxxxx