Fundamental design constraints scgmille@xxxxxx (29 Oct 2003 14:17 UTC)
Re: Fundamental design constraints Bradd W. Szonye (30 Oct 2003 06:00 UTC)
RE: Fundamental design constraints Anton van Straaten (30 Oct 2003 07:19 UTC)
Re: Fundamental design constraints Alex Shinn (30 Oct 2003 07:44 UTC)
Re: Fundamental design constraints Bradd W. Szonye (30 Oct 2003 10:16 UTC)

RE: Fundamental design constraints Anton van Straaten 30 Oct 2003 07:20 UTC

> > 2. Necessary operators (as opposed to a Kitchen Sink):  This follows
> > the general Scheme philosophy ....
>
> Is that really Scheme philosophy, or is it Scheme pragmatism?

It really is Scheme philosophy - it's laid out in the intro to R5RS.

> 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.

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.

> 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 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).

Anton