On Sat, 19 Jun 2004, felix wrote: > xxxxxx@autodrip.bloodandcoffee.net wrote: > > > Come _on_. It's a _simple_configuration_langauge_. It's not like you > > have to relearn Scheme all over again or anything. It's hardly more > > complicated than learning a new special REQUIRE-EXTENSION form. > > > > I agree it's really not hard to learn, but it's unneccessarily cumbersome > (IMHO). Sorry, but this is just an empty arguemnt about your personal taste, and it has absolutely no place in this argument. > >>This is mainly about making it easier for users. You put too much > >>emphasis on implementors. > > > > Excuse me? This is a Scheme Request for Implementation. There won't > > _be_ users if it can't be implemented, or certain Schemes will be > > _alienated_ due to _your_ personal taste! > > SRFI-55 can't be implemented? How come? (and please don't make the mistake > of judging from a _single_ implementation) Yes, SRFI 55 can't be implemented without restructuring a great deal of Scheme48's compiler. I consider only one implementation's module system because it is the only one that I know of that has the property that module data can't be embedded into source data. A quick check shows that RScheme's module system _seems_ to have this property as well, though I'm not _entirely_ sure. But it's irrelevant that I can think of no others; it's a pretty clear property of a module system that module data can't be embedded into code that disallows a REQUIRE- like mechanism, and module systems with that property just should _not_be_alienated_arbitrarily_! > > and your aesthetic tastes. That is not an adequate answer. > > Yeah, sure. How about your aesthetic tastes? Again, this is moving to the issue of taste, which should _not_ be in this discussion as long as technical merit is at issue. > >>Technically, I don't see a problem with both SRFI-0 and SRFI-55. > > > > You are rather blind, then. Please, _READ_ the SRFI 0 discussion > > archive, and notice that Feeley _never_ even _responded_ to the last > > few arguments against his proposal and for a separate configuration > > language! > > So, then I'm blind. Thank you! > > So Feeley never responded. What does that change? Does that fact alone > make SRFI-0 useless? Why are so many Schemes implementing it, then? > Are all those implementors blind too? Those implementors don't have module systems with the same property that Scheme48's and [I think] RScheme's do, so they have no way to see the issue! > > You're using the same argument as is used in SRFI 50, Felix: 'if your > > Scheme is simple enough and has this pre-determined architecture, you > > can use this SRFI.' > > This is in fact wrong. `require-extension' isn't necessarily simple, it's > just easy to use. One of the main arguments for the current SRFI 50 conventions is that it's easier to use than Pika- or JNI-style conventions...and note that I said not just 'is simple enough' but also 'has this pre-determined architecture.' Furthermore, SRFI 7 is hardly more difficult to use than SRFI 55. Yes, it requires a few more keystrokes, but that is _not_ a grounds for asserting difficulty. > See the PLT documentation about `require' how it can > be done inside a very powerful module system. > > (it's amazing to see how this fact is stubbornly ignored) It's amazing to see how the fact that Scheme48's & RScheme's module systems can't implement REQUIRE is stubbornly ignored! I am _not_ saying that REQUIRE-like mechanisms are inherently incompatible with _all_ module systems, but that they _can_ be incompatible with _some_ module systems, whereas a separate configuration language can _always_ be compatible with module systems. > > This is _NOT_ the right way to specify SRFIs. > > So what it the right way? - tell me. To design the SRFI in such a way that it does _not_ restrict itself to certain architectures; to design it in such a way that it is not inherently tied to one kind of architecture; to design it so that it can be compatible with existing architectures, even if some Schemes' precise mechanisms differ from the SRFI. SRFI 55 is _not_ compatible with module systems that don't allow module data to be embedded into Scheme code, yet I defy you to show me a module system, or a design for a module system -- even if it's unimplemented --, that can't support SRFI 7. > > SRFI 7 > > can be implemented to expand to code that uses REQUIRE-EXTENSION if > > your Scheme fits into that category of pre-determined architectures > > with either overly simplistic or no module systems, but it can also be > > implemented in terms of a much more sophisticated module system like > > that of Scheme48's -- where REQUIRE-EXTENSION does _NOT_ work --, or it > > could expand to a PLT module -- in which more information can be > > encoded than with just a sequence of bare S-expressions --. But you > > are arbitrarily choosing to alienate certain implementations because of > > your personal taste! > > I think not. See above and all previous e-mails. Can you clarify what you don't think, and what you want me to scan all previous emails for? Those two sentences responded to a lot of points. > Scheme48 may not be able > to implement it, which I personally find unfortunate. Chicken will not > be able to implement SRFI-21, but I don't feel alienated at all. There is a _huge_ difference here. With SRFI 21, it's a _single_ mechanism -- adding real-time constraints to SRFI 18 -- that is not a duplicate of any other mechanism, and if you can't do real-time multithreading, then there's no reason you'd want it anyways. On the other hand, SRFI 0 is a mechanism for feature-based conditionals, but that sort of thing -- feature-based conditionals -- does _not_ inherently impose module data into Scheme source code, so SRFI 0, which _does_, is flawed. SRFI 7 duplicated some functionality if SRFI 0 because SRFI 0 was flawed, and SRFI 7 _fixed_ the flaw: module data is no longer embedded into Scheme source code, but you can always expand the module data _into_ it, for systems where the module data _must_ be embedded into the source code. SRFI 55 is modifying SRFI 0 slightly, eliminating the 'conditional' part, and it has the _same_flaw_ that SRFI 0 had. Therefore, SRFIs 0 & 55 _unnecessarily_ alienate module systems that disallow embedding module data into Scheme source code, and this is _inherent_ in their design. If you just can't have a real- time scheduler -- _regardless_ of designs inherent in SRFI 21 --, then of course you can't implement it; you can't implement _any_ real-time multithreading mechanism: there's no alienation here except by people who _need_ real-time multithreading. With SRFIs 0 & 55, there's alienation by people who _just_personally_prefer_ embedding module data into Scheme source data; there is no _necessity_ involved. > > Do you really think fracturing it more is going to help? One of the > > main goals of SRFIs is to _mend_ these fractures! > > I think SRFI-55 could standardize a common form for several similar, > already existing forms (which *do* exist). It's just going to make the fracture _more_distinct_, because you're standardizing one way to declare feature requirements while alienating implementations that _cannot_ use this way. SRFI 7 _mended_ the fracture already, but you're proposing to break it open again and make it wider! > > We have SRFI 7 because the author of SRFI 0, just like you, obstinately > > continued with his SRFI even with strong arguments against it. Seven > > SRFIs later, the problem was _fixed_ with a configuration language that > > _avoided_ all sorts of problems. Forty-eight SRFIs after that, you're > > trying to _break_ it again! > > Ahem, nobody is using SRFI-7, at least, I haven't heard or seen about anybody > doing so, being a regular follower of c.l.s and #scheme. Moreover, the number > of implementations supporting it is rather small, compared to the number > of implementations supporting SRFI-0. I see a tendency here. Why are you > ignoring this fact? Why don't you ask some implementors why they don't implement it and some Schemers why they don't use it? I asked a prominent Schemer who writes a great deal of portable Scheme code -- Neil W. Van Dyke --, and his answer was, paraphrased, 'because not enough people implement it.' Catfive on #scheme (is he D. C. Frost?) told me that he was against adding SRFI 7 support because no one used it. This catch-22 has _nothing_ to do with technical merit, and it should be cast off before it does any more damage to a fracture in portability. (Neil also told me that he wanted a way to define his own features, which, hey, SRFI 55 still doesn't provide! (no pun intended)) > > How many quick scripts do you write to be portable across multiple > > Scheme implementations? I sincerely doubt that you write _any_, and so > > it's _not_worth_it_ to try to standardize what will keep you from > > writing a couple keystrokes in quick scripts that will be used for only > > one particular implementation. For those quick scripts that are > > implementation-specific, you can still use whatever mechanism you find > > to have fewer keystrokes, but please, don't base SRFIs off of these > > saved keystrokes for programs that are going to implementation-specific > > anyways. > > No, I don't write many portable scripts. Yet, in writing non-portable > scripts, I like to have convenience at my fingertips. Is this so > undesirable? Am I completely alone on this planet, who likes easy > coding? Do I have to learn Python or Perl do have the right to like > things easy? Reread what I said. If you like REQUIRE-EXTENSION and you're using an implementation that supports it for your scripts, then _go_ahead_: _use_it_. But those quick scripts have _no_ bearing in an argument debating the rationale of whether or not to _standardize_ REQUIRE! > > SRFI 50-style conventions are also pretty widely used. Stop using the > > tactics that are used to defend SRFI 50, Felix, if you're going to > > complain about those same tactics just in the context of SRFI 50. > > If you read what I wrote above, you might see the difference between those > two SRFIs, and the amount of "damage" they could cause. It doesn't matter. Those argument tactics are _not_ effective, _regardless_ of the weight of the argument they are used for. > You cleverly avoid answering the fundamental question: > > "How come others can do it?" This question is too vague for me to answer; I don't know what the antecedent is. If the question is 'how come others can support REQUIRE?' I must tell you that this is _not_ a fundamental question. The answer is that some module systems allow embedding of module data in Scheme code, and others do not. Are you suggesting that all those that do not be redesigned? You're just going to widen that fracture I discussed above _EVEN_MORE_ if you suggest that!
