On Tue, 22 Jun 2004, felix wrote:

> xxxxxx@autodrip.bloodandcoffee.net wrote:
> > On Mon, 21 Jun 2004, Felix Winkelmann wrote:
> >
> > (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.)
>
> I think your preferences are quite clear.

Were you reading anything but the second & third clauses of the second
parenthesized sentence  there?  It is _NOT_ a relevant issue; what you
just said provides _nothing_ to the discussion.

> > 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.
>
> I have answered that already. Apparently not to your full satisfaction.
> I have nothing to add.

You have given _no_answer_ but 'my tastes disagree,' and your tastes
are _nowhere_near_ as important as valid technical merit, which you
have given _no_ indication of in this SRFI.  Saying 'it's too
complicated' is, first of all, entirely subjective -- there go your
tastes again --, and moreover demonstrably over-dramatized.

> >>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!
>
> No, I won't do that. Otherwise SRFI-55 wouldn't have been submitted.

Huh?  SRFI 55 wouldn't have been submitted if it were merely an
amendment to SRFI 7?

> I don't like SRFI-7, for reasons that I already described.

This alone is _no_reason_ to deliberately alienate certain module
systems.

> > 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!
>
> Interesting, but one could say that SRFI-7 is rather unpopular, because
> very few implementations support it. Not that this is in any way
> important, but it may indicate that I'm not entirely alone with my
> disliking of it.

As I said earlier, a significant reason for why SRFI 7 isn't widely
used because it's not very widely implemented, and a significant reason
that it's not widely implemented because it's not widely used.  That's
no basis for technical argument.

> > 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_!
>
> You seem to be rather agitated, Taylor.

What a useful response.  Do you have one any less useful, or do you
implicitly concede the point?

(I get one free sarcastic comment because of yours in your last email!)

> >>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!
>
> Am I? I don't get the impression.

You just said that certain implementations shouldn't restrict others.
SRFI 55 -- effectively, Chicken, for the sake of this point -- is
restricting Schemes to module systems that embed module data in Scheme
code, whereas SRFI 7 is not.  Therefore you just contradicted yourself
by saying that certain implementations shouldn't restrict others while
at the same time supporting one that does.

> >                                                              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!
>
> I've seen numerous people being quite confused with this separation
> (as in Scheme48, for example), especially newbies. I don't think
> this should be necessary. Easy things should be easy, in my opinion.

Most newbies are confused by higher-order & anonymous closures, too.
Maybe we ought to just get rid of them.

It _is_ easy already, and it just requires a little bit of explanation
to some newbies, just as higher-order & anonymous closures do.  I know
from experience that newbies tend to lose confusion quickly about the
Scheme48 module system after a decent explanation.

> Defining a new language just to have access to a few list-processing
> functions is too much (IMHO), but I've said that before...

The innocent 'just to have access to a few list-processing functions'
is vastly disguising the real purpose.  Why define a new language just
to manipulate some bits in memory?  It's for a more sophisticated
purpose than 'just a few list-processing functions': it's a dependency
specification language.  Why define a new file format for Debian or
DarwinPorts or whatever packages?  If all you want to make use of is a
certain feature of it -- the REQUIRES clause --, you don't need to
encumber yourself with the rest of the language, but for those who _do_
use the rest of the language, it _should_ be there, and it should
_also_ not be specified so that it can't work in certain environments
just due to the arbitrary taste of Felix Winkelmann.

> >>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.
>
> No, but more complicated than necessary.

Compare:

(require-extension (srfi 1)) ...
(program (requires srfi-1) (code ...))

Is that _REALLY_ much more complicated?