This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 contain all messages, not just those from before July 7th, 2015.
Votes on issues on which I have an opinion, and discussion of a couple of the issues: iota defn Count based Naming: iota (IOTA ...) only circular lists See below. improper lists See below. TAKE & DROP Separate left and right versions. Removing PROPER-LIST? Yes. map function termination condition #1. FIND, FIND-TAIL n-ary No. alist functions in separate lib? Yes. Are the right-duplicate deletion procedures worth inclusion? Yes. lists-as-sets funs put in separate module? Yes. Naming: REMOVE / DELETE conflicts Happy with your sol'n. Naming: right & left variants See below. destructive/linear-update See below. Naming: ACONS or ALIST-CONS? ALIST-CONS. Argument order of = equivalence predicates Spell it out. Circular and improper lists: I am opposed to even acknowledging the existence of circular and improper "lists" in the proposal. I suggest instead that you break the functionality of the SRFI-1 procedures on circular and improper lists out as a separate SRFI so that implementations that want to support that behavior may do so; I find that I use circular and improper lists only very rarely, and almost always disguised as non-list-like data structures. Naming right and left variants: I argue once again for '-left' and '-right' suffixes, alternately for '' and '-right' suffixes. Artificial succinctness in naming isn't worth the bother it brings about. Destructive/linear-update: Contrary to what you say, your revised proposal does not serve my concern. My concern is threefold: (1) I want side effects. This concern is served by your proposal, although I dislike the secondary status you give procedures with guaranteed side effects. (2) You give existing names new meanings, thus breaking working code and alienating implementers (including myself :-). This concern is not served by your proposal. (3) You give an existing naming convention, the ! suffix, a new meaning. This concern is not served by your proposal. You're constructing a new class of procedures in the language. What's the problem with choosing new names for the new procedures? What's the problem with selecting a naming scheme that does not conflict with those of existing classes of procedures? --lars