This page is part of the web mail archives of SRFI 55 from before July 7th, 2015. The new archives for SRFI 55 contain all messages, not just those from before July 7th, 2015.
campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx 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