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 Wed, 23 Jun 2004, felix wrote: > campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx 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.