2.2.4.1 General discussion

A set of general criteria guided the design of this library.

I don’t require “destructive” (what I call “linear update”) procedures to alter and recycle cons cells from the argument lists. They are allowed to, but not required to. (And the reference implementations I have written do recycle the argument lists.)

List–filtering procedures such as filter or delete do not disorder lists. Elements appear in the answer list in the same order as they appear in the argument list. This constrains implementation, but seems like a desirable feature, since in many uses of lists, order matters. (In particular, disordering an alist is definitely a bad idea.)

Contrariwise, although the reference implementations of the list–filtering procedures share longest common tails between argument and answer lists, it not is part of the spec.

Because lists are an inherently sequential data structure (unlike, say, vectors), list–inspection functions such as find, find-tail, for-each, any and every commit to a left–to–right traversal order of their argument list.

However, constructor functions, such as list-tabulate and the mapping procedures (append-map, append-map!, map!, pair-for-each, filter-map, map-in-order), do not specify the dynamic order in which their procedural argument is applied to its various values.

Predicates return useful true values wherever possible. Thus any must return the true value produced by its predicate, and every returns the final true value produced by applying its predicate argument to the last element of its argument list.

Functionality is provided both in pure and linear–update (potentially destructive) forms wherever this makes sense.

No special status accorded Scheme’s built–in equality functions. Any functionality provided in terms of eq?, eqv?, equal? is also available using a client–provided equality function.

Proper design counts for more than backwards compatibility, but I have tried, ceteris paribus, to be as backwards–compatible as possible with existing list–processing libraries, in order to facilitate porting old code to run as a client of the procedures in this library. Name choices and semantics are, for the most part, in agreement with existing practice in many current Scheme systems. I have indicated some incompatibilities in the following text.

These procedures are not “sequence generic”—-i.e. procedures that operate on either vectors and lists. They are list–specific. I prefer to keep the library simple and focused.

I have named these procedures without a qualifying initial list- lexeme, which is in keeping with the existing set of list–processing utilities in Scheme. I follow the general Scheme convention (vector-length, string-ref) of placing the type–name before the action when naming procedures—-so we have list-copy and pair-for-each rather than the perhaps more fluid, but less consistent, copy-list or for-each-pair.

I have generally followed a regular and consistent naming scheme, composing procedure names from a set of basic lexemes.