[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems with rationale & design

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

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

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

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.