Digrasp
Previously
I said that dotted graphs seem to be second class objects and John asked me to elaborate.
How are dotted graphs second class?
A number of combiners in the spec accept cyclic but not dotted lists. These are:
- All the type predicates
- map and for-each
- list-neighbors
- append and append!
- filter
- reduce
- "Constructably circular" combiners like $sequence
So they accept any undotted graph, but not general dotted graphs. This occurs often enough that to make dotted graphs seem second-class.
Could it be otherwise?
The "no way" cases
For some combiners I think there is no sane alternative, like `pair?' and the appends.
The "too painful" cases
For others, like filter or list-neighbors, the dotted end could have been treated like an item, but it seems klugey and irregular, and they can't do anything sane with a "unary dotted list", ie a non-list.
$sequence etc seem to belong here.
map and for-each
For map and for-each, dotted lists at the top level have the same problem as above, but ISTM "secondary" dotted lists and lists of varying length could work.
Those could be accomodated by passing another combiner argument
(proc2
) that, when any list runs out, is given the remaining tails
isomorphically to Args, and its return is used as the tail of the
return list. In other words, map over a "rectangle" of list-of-list
and let proc2 work on the irregular overrun.
The existing behavior could be recaptured by passing a proc2 that, if it gets all nils, returns nil, and otherwise raises error. Other useful behaviors seem possible, such as continuing with default arguments or governing the length of the result by the shortest list.
Reduce
Reduce puzzles me. A cyclic list's cycle after it is collapsed to a single item resembles a dotted tail, and is legal. Does that imply that a dotted list should be able to shortcut to that stage?