This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.
What I want is a simple SRFI-0 that works. We can embellish it in a later SRFI if necessary, but the entire SRFI project will be stillborn if we can't agree on SRFI-0. I could live with Feeley's original draft or with Kelsey's proposal. Both are a bit more general than necessary, in different ways, but that's just a minor quibble. I would be happier to have either one of those proposals be accepted than to delay SRFI-0 beyond the next release date for Larceny. I would be quite unhappy with the SRFI editors' proposal, partly because of the nondeterminism but also because it was so elaborate that its semantics were unclear. My original understanding of the proposal was that the nondeterministic choices were uncorrelated, which just wouldn't work for reasons that Richard Kelsey explained quite well. Then it was explained that the nondeterministic choices were supposed to be correlated, but the precise semantics remained a mystery. Almost 40 years after John McCarthy proposed his AMB operator, the semantics of correlated choice remains a research area with many difficult open problems, and many of the things that we have learned along the way are more complex than most programmers can handle (e.g. CCS, CSP, Petri Nets, call-time versus run-time choice, temporal logic). This is not the kind of thing that people should have to understand in order to use the most basic SRFI. I disagree with Matthew Flatt about the problem that is to be solved by SRFI-0. I agree that modularity is _a_ problem, but it is not _the_ problem that we can reasonably expect SRFI-0 to solve. My view is closer to Donovan Kolbly's, who hopes that SRFIs will contribute to standardization of useful features, but I don't think that is exactly the purpose of SRFI-0 either. In my view, the point of SRFI-0 is to allow Scheme programmers to get their work done. Many of the features that programmers need to use actually do exist in most implementations. Sometimes the interface is the same across several different implementations, sometimes it is slightly different, and sometimes it is greatly different. SRFI-0 allows programmers (whether individuals or teams) to specify the interfaces to those features that are used by a particular program, without requiring the Scheme community as a whole to agree on anything at all, not even on what an "interface" should look like. This is important. We have been needing an intermediate step between the implementation-independent standards and the grungy details of particular implementations. SLIB has served that purpose to some extent, but SLIB has been limited by its failure to separate interface from code. With SRFI-0 we will be able to say that a program is written in R5RS Scheme plus SRFI-0, SRFI-17, SRFI-24, and SRFI-30. That's a lot better than saying that it's written in Scheme 48 v0.36. It tells me something about what I would have to do to make the program run in Larceny v1.0a2 or Gambit v3.0 or even Scheme 48 v0.37. Over time, these SRFIs probably will contribute to standardization. I certainly hope so. But they will serve a purpose even if they don't. -------- I will now suggest how Feeley's and Kelsey's proposals might be simplified. This isn't very important, but having said that I would prefer to simplify them, I feel as though I owe an explanation. I think Feeley's proposal would be improved by adding a very small fixed set of boolean connectives such as AND, OR, NOT. I would be happier if IF-IMPLEMENTS were restricted to top level, and to definitions. I have noted previously that the discussion of case-sensitivity in Feeley's draft is inadequate and would best be deleted. To simplify program transformers, I would like to allow zero definitions where Feeley's proposal requires at least one. With these changes, the syntax of Feeley's proposal would reduce to the following new or altered productions: <program> --> <command> | <definition> | <if-implements> <if-implements> --> (if-implements <feature> <definition>*) <feature> --> <feature-id> | (NOT <feature>) | (OR <feature>*) | (AND <feature>*) <feature-id> --> a symbol which is the name or alias of a SRFI Note that the anonymous objection to names like "SRFI-25" is an objection to the naming conventions that have been adopted by the SRFI editors, and is not in any way an objection to Feeley's syntax or to the above syntax. I think the editors should rethink their naming conventions after some SRFI-0 has been adopted. I think Kelsey's proposal could be simplified by leaving the READER-SYNTAX, FILES, and CODE features to another SRFI, because they are orthogonal to the REQUIRES and FEATURE-COND forms, which suffice for the purpose of SRFI-0. There would not be much difference in practice between this simplified form of Kelsey's proposal and the syntax suggested above. That's what I want. Something simple that would work. Will