[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.

My personal taste has not been brought up _at_all_ in this discussion,
_except_ by you to try to get me to fling up a flimsy defence using my
taste to argue.  _Regardless_ of whether I prefer embedding module
data into Scheme code or separating it cleanly, I'd _still_ argue for
a separate configuration language: a separate configuration language
can easily support module systems that both embed & separate module
data, whereas a REQUIRE form _cannot_ support module systems that
separate module data from source data.

(And please stop trying to make points using my own personal taste.  It
has not been brought up by me at all, and you don't even necessarily
know whether I _personally_ -- regardless of technical merit -- prefer
an embedded or seprate configuration language.  It is just _not_ a
relevant issue.)

> > 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?

Why should individual people arbitrarily alienate certain select
implementations just because of a certain property of their module
systems, when a solution that would _not_ alienate them is readily
possible?  Convenience, anyways, is _hardly_ at issue here, as I have
demonstrated that SRFI 7 requires only a _few_more_keystrokes_ than
SRFI 55.

> > 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.
> > 
> 
> Yes, as I pointed out: the shortcomings of one and a half implementations
> are unfortunate, but shouldn't stand in the way over making things
> easier for the average Scheme programmer.

Sorry, but all you have shown in this area is that you vaguely prefer
REQUIRE for few concrete reasons.  The difference between a REQUIRE
form and SRFI 7 is the PROGRAM & CODE symbols, and only PROGRAM,
really, if you use SRFI 10 or anything.

> > other hand, SRFI 0 is a mechanism for feature-based conditionals, but
> > that sort of thing -- feature-based conditionals -- does _not_
> > inherently impose module data into Scheme source code, so SRFI 0, which
> > _does_, is flawed.  SRFI 7 duplicated some functionality if SRFI 0
> > because SRFI 0 was flawed, and SRFI 7 _fixed_ the flaw: module data is
> > no longer embedded into Scheme source code, but you can always expand
> > the module data _into_ it, for systems where the module data _must_ be
> > embedded into the source code.  SRFI 55 is modifying SRFI 0 slightly,
> > eliminating the 'conditional' part, and it has the _same_flaw_ that
> > SRFI 0 had.  Therefore, SRFIs 0 & 55 _unnecessarily_ alienate module
> > systems that disallow embedding module data into Scheme source code,
> > and this is _inherent_ in their design.  If you just can't have a real-
> > time scheduler -- _regardless_ of designs inherent in SRFI 21 --, then
> > of course you can't implement it; you can't implement _any_ real-time
> > multithreading mechanism: there's no alienation here except by people
> > who _need_ real-time multithreading.  With SRFIs 0 & 55, there's
> > alienation by people who _just_personally_prefer_ embedding module data
> > into Scheme source data; there is no _necessity_ involved.
> 
> To reiterate:
> 
> a) SRFI-55 provides functionality that SRFI-7 doesn't specify (i.e.
>     loading/making accessible SRFI functionality), regardless how
>     you twist the SRFI-7 specification, or the possible ways how it
>     could be interpreted.

This problem is _easily_solved_ with a suggestion I have made _many_
times -- though which you seem to have readily ignored --: just make an
amendment to SRFI 7 that specifies this!

> b) That SRFI-0 is inherently flawed according to your taste, doesn't
>     bother me at all, I think it adequate and useful. It's also implemented
>     across a broad range of implementations, so I see that as an
>     indication that implementors seem to be comfortable with it and that
>     they are willing to implement it.

No, it is flawed according to _NOT_ just my taste.  SRFI 7 _is_ only
according to your taste.  There is _considerable_ difference.  SRFI 7
is implementable across an _even_broader_ range of implementations, yet
_all_you_consider_ here is the range that _your_implementation_ fits
in!  If you want your implementation to support this sort of thing,
_go_ahead_, but _don't_ impose your own system on everyone else when
_not_everyone_ can support it!  On the other hand, you _CAN_ support
SRFI 7, as can the implementations you _alienate_, but you reject it
_just_because_it's_not_quite_as_concise_as_you_might_prefer_!

> c) That some (one, effectively) implementations are not able to support
>     something along SRFI-55 is unfortunate, but should not restrict
>     the abilities of other implementations. Yes, I consider those
>     implementations "broken" in that regard, you are of course free
>     to disagree.

First of all, SRFI 7 does _NOT_ restrict other implementations, while
SRFIs 0 & 55 _DO_, so you're just arguing against yourself!  Second,
you have arbitrarily asserted that module systems that separate module
data from source code are inherently broken, with _absolutely_no_
_consideration_ of _technical_merit_; your _ONLY_ argument against them
has been your personal taste!

Now, I'm not going to go into the details of advantages of having a
separate configuration language right now, because it would rather
needlessly clutter this discussion, but if you'd like me to describe
the advantages, I can certainly do that.  Briefly, it has to do with
[re]loading modules' source code and how it interacts with Scheme48's
interactive late [re]linking & undefined variable caching; this
mechanism _dramatically_ assists dynamic & rapid development, and I've
seen no other Scheme system with this sort of thing, except _maybe_ T,
although I'm not very clear on the details of its mechanics in that
area, and it lacked a module system at all to bring order to namespace
management.

> d) Ease of use is an important issue to me, even if it offends some
>     people's idea of what's the "Right Thing" or not.

Ease of use is important, yes, but _allowing_ for use is necessary for
ease of use!  Furthermore, using SRFI 7 requires only a _few_more_
_keystrokes_ than SRFI 55, which does _not_ exactly make it
extraordinarily difficult.

> So instead of going over this endlessly, I suggest we agree to disagree.

Sorry, but I shall _not_ 'just agree to disagree' when that would
_harm_ portability of Scheme code and _arbitrarily_alienate_certain_
_Scheme_implementations_ with _no_ thought of technical consideration
for those implementations.