[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI naming
Al, I was starting to lean towards your argument, but your last couple
of messages have pushed me back to the status quo.
1) People working with email seem to be quite comfortable talking
about rfc733, rfc822 and rfc2822. And if you're not sure, google
will happily use `rfc email' to give you appropriate references.
2) srfi numbers are for programs. I see nothing whatsoever wrong with
expecting anyone reading my code to go look up srfi-7 and srfi-14
if I reference them in my program (and they're not familiar with
them). In the process they might even look at a bit more
documentation than they would with srfi-config-lang and
srfi-char-lib. The fear as always with abbreviations is that
people think they understand when they actually just know enough to
And similarly, when I'm writing some code and I want a string
library, I'll ask google or my IDE for `srfi string library' and
out pops srfi-13 or srfi-13 and srfi-74, and I can go and look at
the documents to see which one does what I want. I don't see the
So I've come to be fairly strongly against the proposal, especially
with authors choosing their own keywords (the editors choosing or the
semantic clustering proposal sound *slightly* better).
- Re: SRFI naming
- From: Alben Barkley Petrofsky <firstname.lastname@example.org>