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/