[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI-1 round 2 discussion
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?
lists-as-sets funs put in separate module?
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?