On Tue, 22 Jun 2004, felix wrote: > xxxxxx@autodrip.bloodandcoffee.net 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 systems. > > 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. Compare: (require-extension (srfi 1)) ... (program (requires srfi-1) (code ...)) Is that _REALLY_ much more complicated?
