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 Fri, 18 Jun 2004, Felix Winkelmann wrote: > campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote: > > > OK. I'd rather, then, that this not be in the 'Rationale' section. > > Not at all. I think it's well-placed there. There's a great difference between 'example usage' and 'compelling argument for why this SRFI exists.' > > Why, then, is SRFI 55 not _just_ a specification detailing that a SRFI > > 7 program loader (whatever that is) should load the necessary code for > > features? Why is it a completely new mechanism with the _exact_same_ > > problems that the _first_ SRFI already had and that were already dealt > > with by SRFI 7? > > Because we think that SRFI-7 is not simple enough and not straightforward > enough to be really useful. 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. > > OK. Let me clarify a little. Here comes along J. Random Implementor, > > making a new Scheme that he wants to be able to run lots of SRFIs. He > > scans down the list of SRFIs, sees the points against SRFI 0, and > > decides not to implement it. He implements the next few, and gets to > > SRFI 7. Skipping ahead, he also sees SRFI 55. > > 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! > > If he decides not to write a useful SRFI 7 program loader that loads the > > code for features when someone loads a SRFI 7 program that requires > > them, why would he implement SRFI 55 such that it _did_ load the > > necessary code for features? If your answer is 'because SRFI 7 was > > too vague & didn't specify that a useful program loader should load the > > necessary code for features,' my next question is: why is this SRFI not > > just an amendment to SRFI 7 to specify that? > > See above. You have given me a vague, hand-wavy sentence about Schemes with very rudimentary module systems and your aesthetic tastes. That is not an adequate answer. > > If he decides to write a useful SRFI 7 program loader that does indeed > > load necessary code for features, he might think that SRFI 55 is just > > superfluous, or he might implement SRFI 55, and then his implementation > > would have needless clutter duplicating functionality, and, if this > > functionality is standardized, that's really not a good thing, > > especially if the duplicate has strong arguments against it, as SRFI 55 > > & SRFI 0-style mechanisms, where module system data is encoded directly > > in Scheme, do. > > > > Ah, now we get to the point: SRFI-55 offends your taste, just as SRFI-7 > does mine. Well, fair enough. Wrong! My taste is not at issue here. There is a _GREAT_ deal of difference between personal taste and technical argument. > 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! > You really > ought to study the landscape of Scheme implementations (some of them > including quite advanced module systems), specifically those that seem > to manage with one or the other form of `require'. 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 _NOT_ the right way to specify SRFIs. A separate configuration langauge is _NOT_ very complicated, but it _DOES_ easily support _MANY_ more implementation architectures! 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! > >>Fine. Then I suggest that the authors of Scheme48 do not > >>support SRFI-55. I don't have a problem with that. In fact, > >>I think that's one of the great properties of the SRFI system. > > > > Whoa, whoa, whoa. Are you seriously suggesting that we _fracture_ > > portability of Scheme code by having some implementations support one > > way to declare feature requirements and other implementations support > > another way, just because the first way was slightly aesthetically > > unpleasing to one or two Schemers? > > Taylor, it already _is_ fractured? Didn't you notice? Do you really think fracturing it more is going to help? One of the main goals of SRFIs is to _mend_ these fractures! > On the other hand, are you seriously suggesting that we should live > with one (arguably) flawed design, without being able to propose > an alternative? Why do we have SRFI-7 then, with SRFI-0 already existing? 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! SRFIs 0 & 55 have the arguably flawed design you refer to. Please, I beg you to read the SRFI 0 discussion archive before you make empty claims about flawed designs. What you find aesthetically pleasing does _NOT_ constitute technical merit of these SRFIs' designs. > > Incredibly inconvenient? Oh, please. Wrap your code in > > > > (program (requires srfi-x) > > ... > > ) (Er, oops. This should have had (code ...).) > > or have a new file containing > > > > (program (requires srfi-x) (files "code.scm")) > > > > That's _hardly_ more typing than a use of REQUIRE-EXTENSION. > > It's enough typing for me that I'd actually prefer > > (use (srfi x)) > > ...code... > > You might find this unimportant, I don't. I write a lot of code, and a lot > of little scripts. I try to safe keystrokes wherever I can. 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. > Moreover, > I'm absolutely certain that 99% of all Scheme users would find SRFI-55 > more convenient. They don't care about implementors' worries, they just > want the stuff "being there" they need. Aesthetic pleasantry is _not_ at issue here. Again, you're using the _same_ argument tactics as were used to defend SRFI 50: 'Pika-style or JNI-style conventions might be technically superior, but SRFI 50 conventions meet our tastes better'; 'SRFI 0-style & SRFI 55-style feature requirement/conditional forms meet Felix's taste better.' > > It's _not_ overkill, and indeed it is _necessary_ for some SRFIs, such > > as SRFI 10; an implementation that reads in all the source code at once > > and then processing it _cannot_ provide SRFI 10 via REQUIRE-EXTENSION > > without terrible inconveniences (such as requiring that you write it at > > an interactive prompt before loading the program -- which, um, doesn't > > exactly scale to large programs with lots of feature requirements --, > > or put the REQUIRE-EXTENSION in a separate file, at which point there > > would be no reason to use SRFI 55 instead of SRFI 7!), because SRFI 10 > > may modify the reader, but the reader was already invoked and reading > > is all over by the time the Scheme compiler saw it was necessary to > > load SRFI 10. > > Sure. I never actually came upon this problem with real code, but that's > a valid point that can be addressed with other, more convenient (sic) > forms (like `load', for example). Elaborate, please. > Anyway, all this doesn't convince me at all. If you don't like SRFI-55, > ignore it. If you are afraid this proposal will further fracture the > Scheme community, then I think this small "fracturing" is acceptable, > since we are not talking about a fundamental interface which will > influence a large body of code (like, say, SRFI-50...). Gee, you don't think _feature_requirement_ will be used in large bodies of code? > I just wonder why it already exists and is heavily used (albeit disguised > as `require', 'use', or various combinations of `load' and 'import'). > That is what surprises me. 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.