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