Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 20:35 UTC)
Re: Reasons for withdrawal Tom Lord (28 Oct 2003 21:24 UTC)
RE: Reasons for withdrawal Anton van Straaten (28 Oct 2003 22:05 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 22:36 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 22:44 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 23:22 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 02:50 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:19 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 03:31 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:38 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 04:36 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 05:02 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:32 UTC)
Re: Reasons for withdrawal Taylor Campbell (28 Oct 2003 22:56 UTC)
Re: Reasons for withdrawal Taylor Campbell (28 Oct 2003 23:06 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 23:16 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 23:28 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 23:42 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 00:13 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 01:00 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 01:41 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 03:03 UTC)
RE: Reasons for withdrawal Anton van Straaten (29 Oct 2003 05:31 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:54 UTC)
RE: Reasons for withdrawal Anton van Straaten (29 Oct 2003 06:40 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 06:44 UTC)
RE: Reasons for withdrawal Anton van Straaten (29 Oct 2003 07:31 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 07:34 UTC)
Re: Reasons for withdrawal Thien-Thi Nguyen (29 Oct 2003 14:08 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 21:28 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 22:02 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 22:22 UTC)
Re: Reasons for withdrawal Jim White (28 Oct 2003 22:15 UTC)
Re: Reasons for withdrawal Shiro Kawai (29 Oct 2003 01:25 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 01:44 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 04:10 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 04:53 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:10 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 05:17 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:31 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 01:49 UTC)
API conflicts (Was: Re: Reasons for withdrawal) Shiro Kawai (29 Oct 2003 05:48 UTC)
Re: API conflicts Shiro Kawai (29 Oct 2003 06:03 UTC)
Re: API conflicts scgmille@xxxxxx (29 Oct 2003 17:40 UTC)
Re: API conflicts (Was: Re: Reasons for withdrawal) Bradd W. Szonye (29 Oct 2003 06:03 UTC)
Re: API conflicts (Was: Re: Reasons for withdrawal) scgmille@xxxxxx (29 Oct 2003 14:19 UTC)
Re: API conflicts Shiro Kawai (29 Oct 2003 22:25 UTC)
Re: API conflicts scgmille@xxxxxx (29 Oct 2003 22:41 UTC)
Re: API conflicts Taylor Campbell (29 Oct 2003 23:58 UTC)
Re: API conflicts (Was: Re: Reasons for withdrawal) Taylor Campbell (29 Oct 2003 21:40 UTC)
A possible solution? bear (29 Oct 2003 22:59 UTC)
RE: A possible solution? Anton van Straaten (30 Oct 2003 07:40 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 10:07 UTC)
RE: A possible solution? bear (30 Oct 2003 15:13 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 15:20 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 15:27 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 15:39 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 15:43 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 16:11 UTC)
Re: A possible solution? bear (30 Oct 2003 17:02 UTC)
Re: A possible solution? Tom Lord (30 Oct 2003 19:58 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 20:15 UTC)
Re: A possible solution? bear (30 Oct 2003 20:53 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 21:07 UTC)
Re: A possible solution? Taylor Campbell (30 Oct 2003 21:08 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 21:11 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 21:17 UTC)
Re: A possible solution? bear (30 Oct 2003 23:11 UTC)
Re: A possible solution? Alex Shinn (31 Oct 2003 03:03 UTC)
Re: API conflicts Shiro Kawai (29 Oct 2003 23:19 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 00:26 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 05:32 UTC)
Re: API conflicts bear (30 Oct 2003 06:22 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 06:23 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 13:54 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 14:01 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 14:16 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 14:29 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 14:58 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 15:22 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 01:50 UTC)
Re: Reasons for withdrawal Alex Shinn (29 Oct 2003 03:06 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:18 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 03:29 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:37 UTC)
Re: Reasons for withdrawal Alex Shinn (29 Oct 2003 06:16 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 14:25 UTC)
Re: Reasons for withdrawal Alex Shinn (30 Oct 2003 02:19 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (30 Oct 2003 04:42 UTC)
Re: Reasons for withdrawal Alex Shinn (30 Oct 2003 06:22 UTC)

API conflicts (Was: Re: Reasons for withdrawal) Shiro Kawai 29 Oct 2003 05:48 UTC

>From: xxxxxx@freenetproject.org
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