Email list hosting service & mailing list manager


Re: problems with rationale & design Donovan Kolbly 21 Jun 2004 17:56 UTC

On Mon, 21 Jun 2004, Felix Winkelmann wrote:

> xxxxxx@autodrip.bloodandcoffee.net 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
name space.

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
user-initial environment.

(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                    (  xxxxxx@rscheme.org
				     (  http://www.rscheme.org/~donovan/