This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
Tom Lord wrote:
> We have in '*-get-{left,right}' a proposed naming convention.
> Both meta-names name the same thing, according to the spec.
Is this the get-left/right for bags? I've already raised this issue.
These interfaces are inappropriate for bags, which have no concept of
sequence -- if they did, they wouldn't be bags.
This is one of the reasons I've been complaining about the fact that bag
is unimplemented. Warts like this are easy to spot when you try to
implement a concrete bag and realize, "Hey! What does this mean, anyway?
These interfaces don't make sense for a collection with no concept of
direction!"
Likewise, the vector-set! problem wouldn't have lasted as long as it did
if the authors had tried implementing a real project with these
interfaces. It would've surfaced even quicker had they tried to adapt
existing code to use this "more elegant" interface. But they didn't.
That's two defects that arose because of insufficient experience with
the implementation. Maybe there aren't any more defects hiding in the
spec, but I wouldn't bet on it. In the software world, where there are
bugs, there are more bugs, and the only way to flush them out is with
careful verification (code review, testing, and regular use).
Successful naming standards develop in two ways:
1. Somebody publishes a real product with a noticeable style. Other
programmers like the product or the style and imitate it. If it's
library code (like the C standard library or MFC for Windows), they
may imitate the style for consistency with the library calls.
2. A software organization uses a naming standard internally. Best
practices experts develop the style independently, and developers are
required to use it unless they can justify an exception. The experts
keep track of the exceptions and modify the standard to reflect
actual use.
Which model does SRFI-44 follow? Is it attached to a compelling product
that programmers imitate out of admiration? No. Is it a corporate or
product standard that programmers are compelled to follow? No. Does it
include a change process that allows the standard to evolve? No.
I have, however, seen many failed coding standards that tried the
approach of SRFI-44.
This is *why* we've been recommending the "publish a concrete
collections library worthy of imitation" approach. SRFI-44 is trying
approach #2 above, but that's doomed to fail -- finalization is *totally
inappropriate* for that kind of standard. Notice how SRFI authors try to
imitate the interfaces of the "good" SRFIs? That's approach #1 above.
A naming standard SRFI is counterproductive and inappropriate. I've
already explained how SRFI-44 isn't appropriate for a SRFI. I'll add to
that: SRFI isn't appropriate for a naming standard. It's a poor fit in
both directions.
--
Bradd W. Szonye
http://www.szonye.com/bradd