Standards commmittees don't invent new things
John Cowan
and Stillerman, _The Sources of Invention_ (1958) and takes the form
"Committees don't invent, people do." Be that as it may, when committees
do invent, the results are often judged unsatisfactory afterwards.
The reason we call our standards Reports is that they began by reflecting
the existing Schemes of the day, from Maclisp Scheme in R0 and R1 to
a consensus of Schemes in R2-R5. IMNSHO, the R6RS committee went off
the rails when they began to invent, completely ignoring the prior art
in the form of existing implementations and SRFIs (yes, they're flawed,
all processes are flawed, including the one we're evolving here).
The first instinct of a Schemer when faced with a new problem is to invent
something, and I share that instinct. I've come up with my very own
typed-box abstraction too, the merit of which (in my own mind) is that
it's run-time only and doesn't bind any names. MAKE-RECORD-TYPE is the
only global procedure; it takes no arguments and returns five procedures:
a constructor, a predicate, a getter, a setter, and a make-record-subtype
procedure. Which is probably more than you wanted to know. But I would
never propose it for standardization, because that instinct doesn't
serve standards processes well.
People often asked me, during the long period when I was a chair
without a WG, "How do I get something into the standard?" My invariable
reply was: "Write a SRFI, with a portable implementation if possible,
and lobby implementers to package your implementation. If no portable
implementation is possible, lobby implementers to provide your feature.
It helps if you can send them patches."
Of course that doesn't mean that WGs don't have to pick and choose:
they do, and they may need to file off rough corners, use weasel words
to increase implementer flexibility now and then, and otherwise make
adjustments. But make up stuff out of whole cloth? No. Not going there.
--
John Cowan http://ccil.org/~cowan co...@ccil.org
Lope de Vega: "It wonders me I can speak at all. Some caitiff rogue did
rudely yerk me on the knob, wherefrom my wits still wander."
An Englishman: "Ay, a filchman to the nab betimes 'll leave a man
crank for a spell." --Harry Turtledove, Ruled Britannia
Emmanuel Medernach
The first instinct of a Schemer when faced with a new problem is to invent
something, and I share that instinct.
Me too, especially because Scheme is a great language in which expressing new ideas is made easier.
People often asked me, during the long period when I was a chair
without a WG, "How do I get something into the standard?" My invariable
reply was: "Write a SRFI, with a portable implementation if possible,
and lobby implementers to package your implementation. If no portable
implementation is possible, lobby implementers to provide your feature.
It helps if you can send them patches."
Of course that doesn't mean that WGs don't have to pick and choose:
they do, and they may need to file off rough corners, use weasel words
to increase implementer flexibility now and then, and otherwise make
adjustments. But make up stuff out of whole cloth? No. Not going there.
I completely agree with this, we should not ignore what is existing and refrain ourselves from reinventing the wheels.
Regards,
--
Emmanuel Medernach
Neil Van Dyke
and that's an illustrative example to work with...
SRFI-9 is *one* of many credible record and record-related abstractions
that exist in current practice.
SRFI-9 is the most widely *implemented*, due to the political nature of
SRFIs. However, I don't know that SRFI-9 is even the most popular in
*use*, by many definitions, despite the huge practical boost of SRFI-9
having been the first record abstraction that happened to be submitted
by someone as a SRFI. (The SRFI process tends to present a big
"first-mover advantage" situation.)
If we are standardizing, and finding compromise with, current practice,
then SRFI-9 is one of many existing practices that should be considered.
I believe that WG1 has an opportunity to create (well, influence) a
standard that is widely adopted like R5RS was, and that this standard
can accomplish this wide adoption without rubber-stamping SRFIs. I
suggest that we be informed by SRFIs, without implicitly treating them
as standards.
If it turns out that I'm in the minority, and that the WGs are actually
focused on standardizing SRFIs... then I'd suggest that the dominant
strategy for influencing RnRS is not to be involved with RnRS, but
rather to be blitzing the SRFI repository, since these SRFIs would be
given preference over even superior existing practice.
John Cowan
> Talk about your strawmen and counter-factual histories...
Oh really?
> And then there's the one about how a camel is a horse designed by
> committee. (Of course, we're not here to talk about Perl :-)
Perl, whatever else you think of it, is conspicuously the product of a
single hand and mind. It's simply one that doesn't share the particular
values of the Scheme community (as distinct from the people in it;
personally, I love Perl).
[various morale-damaging jokes snipped]
> Oh, man, you should see some of the crazy ideas people talked about
> on the old rrrs list.
Doubtless. But those crazy ideas didn't make it into the Reports.
> Your point is well taken that we should try to avoid going completely
> off the rails but pretty much all but the first couple of Reports were
> not quite reports in the strict sense that you describe.
Quite.
> Heck, even our charter explicitly encourages a certain amount of
> invention, for specific purposes.
Modules, yes; completing the square, yes.
> I don't think we'll make any progress bickering about the philosophy
> of what we're trying to do, whether one's position is "let's introduce
> new thing X" or "any introduction of a new thing is inherently wrong".
> The only answer likely to stick for such questions is "Well, it depends
> on the value of X." The meta-questions have no definitive answer.
I agree. And who's bickering? I stated where I stand, that's all.
> We're, like, a month down with 5 to go before our first
> deliverable. About 17% of our time for the first milestone
> is now already gone. Yikes!
Go read some issues and add comments. Or add more issues, then.
> Let's do the easy stuff and get some momentum going,
I agree with that too. Unfortunately, we don't seem to agree on what's
easy and what's hard.
> Anyone have any objection to taking the spec of the Boolean type more
> or less directly out of R5? We can play around with the exact wording
> to fit the larger document we create but do we all agree that the R5
> spec is reasonable? I'll knock out a translation into some simple XML
> from which we can easily generate both hypertext and a printed version,
> unless someone else wishes to volunteer. If I *did* just nominate
> myself for such drudge-work, I'd welcome a volunteer who will write
> some (hopefully easy) XSLT to generate, say, texinfo while I worry
> about the XSLT to generate hypertext.
Go for it.
--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
"After all, would you consider a man without honor wealthy, even if his
Dinar laid end to end would reach from here to the Temple of Toplat?"
"No, I wouldn't", the beggar replied. "Why is that?" the Master asked.
"A Dinar doesn't go very far these days, Master. --Kehlog Albran
Besides, the Temple of Toplat is across the street." The Profit
John Cowan
> If we are standardizing, and finding compromise with, current practice,
> then SRFI-9 is one of many existing practices that should be considered.
I agree. Please feel free to propose alternatives.
> I believe that WG1 has an opportunity to create (well, influence) a
> standard that is widely adopted like R5RS was, and that this standard
> can accomplish this wide adoption without rubber-stamping SRFIs. I
> suggest that we be informed by SRFIs, without implicitly treating them
> as standards.
I agree with that too.
> If it turns out that I'm in the minority, and that the WGs are actually
> focused on standardizing SRFIs... then I'd suggest that the dominant
> strategy for influencing RnRS is not to be involved with RnRS, but
> rather to be blitzing the SRFI repository, since these SRFIs would be
> given preference over even superior existing practice.
Remember that the original poster's question was much more narrowly
focused: given incompatible SRFI and R6RS solutions of _equal technical
merit_, which should we prefer? My reply was, "the SRFI".
--
First known example of political correctness: John Cowan
After Nurhachi had united all the other http://www.ccil.org/~cowan
Jurchen tribes under the leadership of the co...@ccil.org
Manchus, his successor Abahai (1592-1643)
issued an order that the name Jurchen should --S. Robert Ramsey,
be banned, and from then on, they were all The Languages of China
to be called Manchus.