Email list hosting service & mailing list manager

Update, near finalization David Van Horn (08 Apr 2005 16:35 UTC)
Re: Update, near finalization Per Bothner (08 Apr 2005 17:35 UTC)
Re: Update, near finalization Aubrey Jaffer (08 Apr 2005 20:16 UTC)
Re: Update, near finalization Per Bothner (08 Apr 2005 21:22 UTC)
Re: Update, near finalization Aubrey Jaffer (10 Apr 2005 21:09 UTC)
Re: Update, near finalization Per Bothner (11 Apr 2005 06:23 UTC)
Re: Update, near finalization Aubrey Jaffer (11 Apr 2005 16:38 UTC)
R6RS process Mitchell Wand (11 Apr 2005 17:17 UTC)

Re: Update, near finalization Aubrey Jaffer 08 Apr 2005 20:16 UTC

 | Date: Fri, 08 Apr 2005 10:34:54 -0700
 | From: Per Bothner <xxxxxx@bothner.com>
 |
 | David Van Horn wrote:
 | > The draft of SRFI 63 Homogeneous and Heterogeneous Arrays has been
 | > updated to resolve the Issues section (cf previous drafts).  This draft
 | > will be finalized if there are no concerns raised in the next couple of
 | > days.
 | >
 | >    http://srfi.schemers.org/srfi-63/srfi-63.html
 |
 | I strongly object.  array-set! is inconsistent with srfi-25, and you
 | cannot distinguish between the variants by their arguments types.

This works by the implementation knowing the difference between
SRFI-25 arrays and SRFI-63 arrays.  This difference can be hidden
entirely from the user.

I claim that SRFI-25 and SRFI-63 can coexist -- not that they
interoperate!

 | This is a recipe for disaster.
 |
 | STFI-25:
 | (array-set! array k ... obj)
 | (array-set! array index obj)
 | SRFI-63:
 | (array-set! array obj k1 ...)
 |
 | It is claimed that "Type dispatch on the first argument to
 | array-set!  could support both SRFIs simultaneously."  I don't
 | believe that.
 | How would you handle:
 | (define array (vector 'a 'b))
 | (set! array 1 0)
 | Is the result #(a 0) or #(1 b)?

SRFI-25 says:

  It is not required that vectors not be arrays.  It is not required
  that they be, either.

For your example to be ambiguous, you would be depending on
unspecified behavior of SRFI-25.

But vectors are mandated to be arrays in SRFI-63.  So the result of
your example would be #(1 b).

 | make-array is also inconsistent:
 | SRFI-25:
 | (make-array shape)
 | (make-array shape obj)
 | SRFI-63:
 | (make-array prototype k1 ...)
 | It is claimed that: "Type dispatch on the first argument to
 | make-array could support both SRFIs simultaneously."  I don't
 | believe that is correct, as written, since a SRFI-25 shape is a d*2
 | array, and a SRFI-67 prototype can also be an array.  Thus they can
 | conflict.

By vectors being SRFI-63 arrays, not SRFI-25 arrays; and by the
implementation knowing the difference between SRFI-25 arrays and
SRFI-63 arrays, there is no conflict.

 | Consider:
 | (define v (shape 0 1))
 | (make-array v 10)

Shape returns a SRFI-25 array, not a vector.  Your example would
return a SRFI-25 array.

 | The conflict can be avoided by requiring that prototypes have rank 0
 | or 1, which seems a reasonable restriction.
 |
 | Much cleaner would be to choose a different name.

Bawden arrays predate SRFI-25 by a decade.  SRFI-25 should have chosen
other names.