[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with rationale & design
On Tue, 22 Jun 2004, felix wrote:
> campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> > On Mon, 21 Jun 2004, Felix Winkelmann wrote:
> > (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.
Were you reading anything but the second & third clauses of the second
parenthesized sentence there? It is _NOT_ a relevant issue; what you
just said provides _nothing_ to the discussion.
> > 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.
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.
> >>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.
Huh? SRFI 55 wouldn't have been submitted if it were merely an
amendment to SRFI 7?
> I don't like SRFI-7, for reasons that I already described.
This alone is _no_reason_ to deliberately alienate certain module
> > 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.
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.
> > 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.
What a useful response. Do you have one any less useful, or do you
implicitly concede the point?
(I get one free sarcastic comment because of yours in your last email!)
> >>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 just said that certain implementations shouldn't restrict others.
SRFI 55 -- effectively, Chicken, for the sake of this point -- 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.
> > 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!
> 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.
Most newbies are confused by higher-order & anonymous closures, too.
Maybe we ought to just get rid of them.
It _is_ easy already, and it just requires a little bit of explanation
to some newbies, just as higher-order & anonymous closures do. I know
from experience that newbies tend to lose confusion quickly about the
Scheme48 module system after a decent explanation.
> Defining a new language just to have access to a few list-processing
> functions is too much (IMHO), but I've said that before...
The innocent 'just to have access to a few list-processing functions'
is vastly disguising the real purpose. Why define a new language just
to manipulate some bits in memory? It's for a more sophisticated
purpose than 'just a few list-processing functions': it's a dependency
specification language. Why define a new file format for Debian or
DarwinPorts or whatever packages? If all you want to make use of is a
certain feature of it -- the REQUIRES clause --, you don't need to
encumber yourself with the rest of the language, but for those who _do_
use the rest of the language, it _should_ be there, and it should
_also_ not be specified so that it can't work in certain environments
just due to the arbitrary taste of Felix Winkelmann.
> >>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.
(require-extension (srfi 1)) ...
(program (requires srfi-1) (code ...))
Is that _REALLY_ much more complicated?