On Wed, 23 Jun 2004, felix wrote: > xxxxxx@autodrip.bloodandcoffee.net wrote: > > > I can't do anything about SRFI 0, Felix, and Feeley, as far as I know, > > ignored the last few arguments that were made against an embedded > > COND-EXPAND on the SRFI 0 discussion! The only option for Scheme48 in > > the SRFI 0 case is to ignore it, but since SRFI 55 is not yet set in > > stone, I can still argue against it and attempt to change it. SRFIs 0 > > & 55 _force_ the fracturing: Scheme48 _can't_help_it_; all it _can_ do > > is ignore them. You're trying to accuse Scheme48 of fracturing itself, > > but _you_ are in fact creating the fracture! > > I'm not trying to accuse Scheme48 of anything, I just wanted to show > that the argument of "fracturing" that you brought up can be applied > to Scheme48 (or better, the authors of SRFI-7) just as well. No, that's simply _untrue_, because SRFI 7, _inherent_ in its design, can _mend_ the fracture; it _would_, if there weren't people like you sitting in the middle of the fracture, pushing it apart, and refusing to budge from your position. SRFI 7 _can_ work with module systems that use a separate configuration language, while SRFI 55 _cannot_. SRFI 7 can _also_ work in _your_ Scheme system -- indeed, as well as any that embeds module data into Scheme code --, but you _reject_ it and try to push that fracture wider with your own system. Then you try to reverse the argument, which demonstrates that either you don't understand it -- SRFI 7 _inherently_ supports more module systems than SRFI 55, but the converse is _not_true_ --, or you're just out of ideas for ways to argue back against me. > > SRFI 0 was already in existence, and I believe it was finalized, by the > > time SRFI 7 was submitted. SRFI 0 worked with many implementations, > > and those implementors who didn't read the discussion archives probably > > found SRFI 7 to be unnecessarily repetitive, _ignoring_ the problems it > > causes with all module systems that have a certain property. > > Sure, they are all blind and ignorant. Unfortunately the Scheme community > hasn't more of those bright, foresighted people like you. Please. I was _not_ claiming that I'm a prophet and they're the mass of ignorance scrounging in the streets. Rather, 'they' simply have no reason to consider the module systems whose module systems _do_ use a separate configuration language. > > I'm not claiming, and I don't think I have in this discussion claimed > > -- aside from mentioning what advantages Scheme48 can gain --, that a > > separate configuration language is inherently better. > > Of course you did. Quote me. By 'a separate configuration language is inherently better,' I refer specifically to the native module system in a Scheme, by the way, not what can be standardized. But that ought to have been clear from the text following that. > > But it _does_ > > permit _not only_ module systems that use a separate configuration > > language but _also_ module systems that embed module data into Scheme > > code. REQUIRE does _not_ permit both. So, to elaborate on the choice: > > > > - For implementations that use a separate configuration language, > > there is _only_one_choice_: SRFI 7, or some other configuration > > language (like the one I pointed out on c.l.scheme recently). > > > > - For implementations that embed module data into Scheme code, they > > can either use SRFI 7 _or_ a REQUIRE mechanism. > > Great, the majority uses a REQUIRE mechanism. To increase portability, > SRFI-55 proposes a common mechanism for this. To increase portability _beyond_ what _just_you_ care about, you could use SRFI 7 and not bother with a new SRFI! (Except to amend SRFI 7 to discuss loading features' code, if you really find that necessary.) SRFI 7 is an _even_more_common_ mechanism than what SRFI 55 defines. SRFI 7 _already_supports_ those implementations that use a REQUIRE mechanism, but you're choosing to sit in the fracture, pushing it further & further apart with SRFI 55, rather than getting out of it and helping mend it by using SRFI 7. > > If you continue with a REQUIRE-like mechanism, the implementations that > > depend on a separate configuration language are _FORCED_ not to support > > the SRFI, but the implementations that already support such a mechanism > > would feel _ENCOURAGED_ to support SRFI 55. That is a _very_clear_ > > fracture that should _not_be_there_. > > No, the "fracture" is already there: currently we have SRFI-7 (supported > by very few implementations) and various REQUIRE-like mechanisms. SRFI 7 _can_support_ those REQUIRE mechanisms. The converse is _not_ _true_. So those Schemes that use REQUIRE mechanisms _can_use_ SRFI 7, quite trivially. That's _not_ a fracture. > By standardizing the latter, we can make it at least a little bit > easier to write portably code for the majority of Scheme implementations. This, on the other hand, _is_ a fracture, _just_ to save a couple key- strokes! Those implementations that separate module data from Scheme code _cannot_ use SRFI 55, while they _can_ use SRFI 7; whereas those that use a REQUIRE-like mechanism can use _both_. By standardizing the option that only _some_ can support, you're _fracturing_, Felix. You cannot flip the argument back around at me. > > In this situation, _YOU_ are > > making the choice for all these implementations, and the choice will > > cause a _fracture_! > > No, you don't understand. Gee, do you think it would be very useful for me to say 'no, you don't understand' in response to that? It wasn't a very useful response from you. I suggest that you come up with something more articulate and coherent. Here I notice that you snipped off a significant paragraph I wrote, not even bothering to respond to it. > > (Remember, though: for all those little quick scripts you write, you > > can _still_ use REQUIRE, because your implementation supports it, and > > portability doesn't matter there! Indeed, if I wanted to save those > > keystrokes while using scsh, I'd use the -o option on the scsh command > > line, which is _even_more_concise_ than REQUIRE!) > > But that wouldn't be portable across multiple implementations. No, it wouldn't. Nor is REQUIRE portable across all implementations. But _SRFI_7_is_! > Anyway, you haven't convinced me, and by repeating it endlessly and by > abusing your "_" key, you will not convince me in future. So I recommend > you change your strategy or simple accept that you can't do anything > about it, unless you try something new. Felix, I recommend that you just try to _understand_ the situation that you are _forcing_ Scheme into. The way you have attempted to flip my argument around and use it against me demonstrates that you hardly understand it at all.
