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

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