This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
From: scgmille@xxxxxxxxxxxxxxxxxx
Subject: Re: Reasons for withdrawal
Date: Tue, 28 Oct 2003 19:49:38 -0600
> BTW, did the concerns you raised earlier get adequately addressed in the
> draft at http://sgmiller.org/code/srfi-44.html?
"Size versus Length" section is now clear enough, I think.
I'd still like to see a section or a note that refers to names
which conflicts or confusing with existing srfis and popular
implementations. It may be a job of users to look them out,
but having mentioned it in this srfi would be a great help
for users and implementators. Something like the following.
Compatibilities:
Some of the names defined in this srfi uses the same or
similar name in existing srfis or implementations. Some of
them are defined so that they are extension of the existing
practice, and some of them have incompatibilities.
Extensions to R5RS
R5RS doesn't specify the return value of string-set! and
vector-set!. This srfi specifies them to return the passed
collection.
string-ref, vector-ref and list-ref are extended to take
an optional argument, absence-thunk.
Relation to other SRFIs
string= has different interface from string= in srfi-13,
which has the following API:
(string= string1 string2 [start1 end1 start2 end2])
If the implementation wish to support both srfis, it can
dispatch by its argument types.
string-copy and string-count are subset of srfi-13's.
string-contains? has a similar name to string-contains in
srfi-13, but the latter looks for substring match, instead
of element-wise match.
list= in this srfi takes two lists. list= in srfi-1 takes
arbitrary number of lists.
Both arguments of make-list in this srfi are optional.
Only the last argument of make-list in srfi-1 is optional.
alist-copy is an extension of srfi-1's. SRFI-1's alist-copy
doesn't specify the behavior when the given argument contains
non-pair in the list. This srfi's alist-copy treats the first
element specially. [This actually suggests the choice of
'alist-' prefix may not be adequate, since the alist dictionary
given in srfi-44 is not really a plain alist. For example,
when people see alist?, they might think something like
(define (alist? obj) (and (proper-list? pbj) (every pair? obj)))
but it's not the case here. It's even obscure whether ordinary
alist operations such as assq, assv, assoc can be applicable to
this alist dictionary. Maybe 'alist-dict-' prefix would be better].
srfi-1 uses "remove" and "delete" in a consistent way;
the functions with "remove" takes a predicate, while the ones
with "delete" takes a value to be compared to the element.
In this srfi, "remove" and "delete" also have a consistent meaning,
but different from srfi-1's.
Consequently, there are a few procedures that have confusingly
similar names with different signatures.
srfi-1 : alist-delete key alist [=]
srfi-44: alist-remove alist key
srfi-1 : alist-delete! key alist [=]
srfi-44: alist-remove! alist key
srfi-1 : remove pred list
srfi-44: list-remove list value
srfi-1 : remove! pred list
srfi-44: list-remove! list value
srfi-1 : delete value list [=]
srfi-44: list-delete list index
srfi-1 : delete! value list [=]
srfi-44: list-delete! list index
Relation to existing implementations
Some implementations (e.g. PLT) use absence-thunk to give a
default value in ?-ref or ?-get API. Other implementations
(e.g. Chicken, STk, Gauche) instead allow an optional value
to specify a default value. This srfi takes the thunk approach
because .....
[Gauche has extended string-ref, vector-ref and list-ref.
Chicken and STk don't have them, but for example they have
hash-table-{ref|get} that takes an optional default value, which
would conflict if somebody wants to implement a hash table
as a dictionary.]
[This has persional bias: Gauche has string-size that
returns number of bytes the multibyte string occupies]
--shiro