xxxxxx@autodrip.bloodandcoffee.net wrote:

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

I did say what I consider technical merit, but you chose to ignore it.

>>>
>>>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 (we, actually) wouldn't have submitted SRFI-55, if we would have
been interested in amending SRFI-7 (because then we would have done
so). It's quite easy to understand, IMHO.

>
>
>>I don't like SRFI-7, for reasons that I already described.
>
>
> This alone is _no_reason_ to deliberately alienate certain module
> systems.
>

I think "alienate" is too strong, and indicates that you
just get a little bit too emotional over the whole issue.

As I said before, If Scheme48's module system is not able to
cope with require-extension, then it's unfortunate, but can't
be helped. Yor argument looks somewhat artifical: by proposing
a feature that Scheme48 can not implement you accuse me of
"alienating certain implementations", but on my reply that
this implementation may choose to ignore SRFI-55, you accuse
me of trying to "fracture" the Scheme community. Yet, this
very implementation (Scheme48) chooses to ignore SRFI-0, thus
doing exactly that ("fracturing").

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

It is of course a basis for a technical argument. Sometimes one
should look at the existing situation and draw conclusions from
actual, practical use - from experience, so to speak. Implementors
like to add SRFIs to their feature-list, and SRFI-7 isn't particularly
hard to implement, so why are so few implementations supporting
it? Did it stop implementors to add support for certain SRFIs, when
they where freshly finalized, even though nobody was actually using them,
yet? Of course not (they were new after all).

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

It's about as useful as merely repeating your argument, hoping
to pound it in by pure brute force. Sorry, that doesn't work in this
case.

> You just said that certain implementations shouldn't restrict others.
> SRFI 55 -- effectively, Chicken, for the sake of this point --

Interesting... Chicken? Why not PLT? Are you trying to say something
here?

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

You forget that implementations have a choice. They may choose to
implement SRFI-7 or SRFI-55, according to whatever they prefer.
It's you who claims to know The Right Way, and who apparently wants to
make that choice for others.

cheers,
felix