On Wednesday, Oct 29, 2003, at 00:48 US/Eastern, Shiro Kawai wrote:
> 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.
I just want to stress the fact that these are _extensions_ and not
incompatibilities.
> 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.
I think SRFI 13's STRING= is the problem here. It breaks the
convention defined by SRFI 1, and SRFIs 43 and 44 use that same
convention; SRFI 13's STRING= is really R5RS's STRING=?, but with the
question mark removed for no reason I can find.
(oops: having read your email over again, I realize that it was just
a list of related work/extensions/incompatibilities; this comment is
therefore irrelevant to this message, but it's still a comment I'd
like to make somewhere)
> string-copy and string-count are subset of srfi-13's.
*-COPY for sequences _used_ to be like SRFI 13's STRING-COPY and SRFI
43's VECTOR-COPY. I'm not sure where this changed, and I'll see if
Scott will put that back in. The same applies to *-COUNT for
sequences, except without it having been extended for sequences in
prior versions of the document.
In fact, it seems like it would make sense for a lot of the bag and
general collection operations to be able to accept start and end
arguments for the sequence versions, e.g. *->LIST, *-REMOVE-whatever,
et cetera.
> [...]
>
> list= in this srfi takes two lists. list= in srfi-1 takes
> arbitrary number of lists.
LIST= should be n-ary. I'm not sure why it isn't. (probably a typo;
there are lots of those in the document, due to the tedium in writing
it)
> [...]
>
> 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].
A couple of problems with alists have been mentioned. Three solutions
came up on IRC:
- Create an abstract type for alists.
Advantages: removes the type conflicts that Tom mentioned
Disadvantages: _no_ list-processing routines work on abstract
and opaque alists, that definition of ALIST? still doesn't
work, and ASS{Q,V,OC} still don't work.
- Add a unique token to the head of the alist.
Advantages: removes the type conflicts
Disadvantages: that definition of ALIST? still doesn't work, and
ASS{Q,V,OC} still don't work.
- Add a metadata _association_ to the list, with a unique token
visible only to the implementation. This metadata could contain
the equivalence functions and even more, perhaps.
Advantages: removes the type conflicts, your ALIST? works, and
ASS{Q,V,OC} work.
Disadvantages: there probably are some that I just can't
remember now...Matthias brought this one up months ago, and I
didn't implement it; I probably had _some_ reason for not
implementing it.
> 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.
> [...]
I don't think these matter much. They aren't _incompatible_, anyways,
though I suppose it might be worth mentioning.
> 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.]
It's pretty easy to avoid this conflict by either not explicitly using
SRFI 44 or explicitly using those implementations' libraries, or
having a simple SRFI 44 wrapper around hash tables of those
implementations when you do explicitly use SRFI 44.
> [This has persional bias: Gauche has string-size that
> returns number of bytes the multibyte string occupies]
>
>
> --shiro
