xxxxxx@autodrip.bloodandcoffee.net wrote:
> On Mon, 21 Jun 2004, Felix Winkelmann wrote:
>
>
> 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.

Ok, I know this already.

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

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

I have answered that already. Apparently not to your full satisfaction.
I have nothing to add.

>>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.
I don't like SRFI-7, for reasons that I already described.

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

In any case, you are repeating yourself (and I'm, too).

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

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

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

Yes, "broken" was a strong term, intended to be slightly provocative.
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.
Defining a new language just to have access to a few list-processing
functions is too much (IMHO), but I've said that before...

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

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

Then go ahead, rescue the Scheme princess from the fangs of the evil
Scheme demon. Man, calm down. You wont get anywhere if you continue
like this...

cheers,
felix