[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fundamental design constraints

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.



Bradd wrote:
>> A recent c.l.s. explanation of the minimalism in R5RS claimed that it
>> wasn't for philosophical reasons, but simply to avoid conflicts with
>> existing implementations.

Anton van Straaten wrote:
> That's a somewhat different situation, and a one-sentence summary
> doesn't do it justice - i.e., is essentially wrong.  There are a lot
> of factors that make it difficult to develop a core Scheme standard
> like RnRS.

Hm, OK, I'll trust you on that for now.

>> If that's true, then this SRFI isn't following the principles, since
>> it isn't a compromise between existing implementations. Indeed, it
>> mostly seems to ignore prior art and set off in its own direction.

> What prior art, in Scheme implementations, is there in this area?
> There are collections, but are there any with a common set of generic
> interfaces?

The SRFI casually stomps on the naming conventions of those individual
collections; it doesn't coexist with them peacefully. The author has
stated that the conflicts and potential confusion with existing
collections are "minor," and his general attitude has been that it's the
user's fault if this causes trouble.

It would be much better to incorporate the conventions of these existing
collection types. Of course, they aren't terribly consistent, so that
probably isn't possible in general. However, actually conflicting with
those interfaces isn't going to win any admirers, and it's likely to
cause widespread non-adoption. What good is a "generic collection"
interface that doesn't actually work well with the collections you
already have?

I get the impression that this spec just wants to forge ahead and ignore
the past, but that doesn't actually work in practice. There's too much
"wouldn't this be cool?" and not enough "will it actually work?"

> The prior art I'm aware of is mostly listed at the bottom of SRFI-44.
> To that I'd add the C++ STL, and things like Common Lisp's sequences
> (which operate only on lists and vectors).

While the C++ STL isn't a perfect role model, a generic collection API
would do well to pay attention to STL's metaprogramming-friendly design.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd