[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems with rationale & design

This page is part of the web mail archives of SRFI 55 from before July 7th, 2015. The new archives for SRFI 55 contain all messages, not just those from before July 7th, 2015.



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