[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:
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

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

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.

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