This page is part of the web mail archives of SRFI 40 from before July 7th, 2015. The new archives for SRFI 40 contain all messages, not just those from before July 7th, 2015.
From: Phil Bewig <pbewig@xxxxxxxxxx> Date: Wed, 12 Feb 2003 16:24:51 +0100 References: <E18imE7-0005Q9-00@rosebud> Everyone who has seen a preliminary draft of this SRFI had the same comment that it should be split into "essential" and "library" pieces, but all had different ideas of where to make the split. I don't care too much about where the split happens as long as the core part isn't too big. A dozen or so procedures and macros should be enough to be useful while not being overwhelming. R5RS provides some guidance by including some functions on lists that it clearly labels "library procedures." But note that the 'library' procedures are still included in the report. It's a distinction based on implementation issues and has nothing to do with clarity or utility. And [R5RS] omits such useful functions as FOLD and FILTER that are the basis of many other functions; you could even claim that FOLD should be included but LENGTH should be excluded, on the grounds that LENGTH is an easy one-liner given FOLD (I followed that logic when I moved LENGTH to the example section). A list's length is one of its fundamental properties. There are a zillion different versions of FOLD. I once wrote a macro to construct new versions as needed. I guess my answer is pragmatic; include everything analogous to R5RS and the haskell prelude on the grounds that anything less leaves users of the library unsatisfied, then take the time to discuss all the pieces and produce something truly useful. Just make sure that the situations are analogous. For example, some of the R5RS list procedures are typically used for S-expressions and are going to be less useful for streams. Similarly, whether a particular procedure did or didn't make it into the Haskell prelude may have more to do with Haskell's syntax or semantics than with the procedure's utility in Scheme. And what do you do about something like FILTER, which can be implemented without knowledge of the underlying representation but can use that knowledge to be much more efficient? Splitting into two SRFIs doesn't mean that the implementation needs to be split. The implementation in the library SRFI can assume the use of the implementation in the core SRFI. Although I left it off of my list I think FILTER should go into the core because of its combined utility and complexity. People can't just generate it when needed. And what would you do with CADADR? I would drop it and all its friends. The C[AD]+R's beyond CAR and CDR are used more with general S-expressions than with proper lists. -Richard