Brad Lucier writes:
> Radey Shouman writes:
>> Per Bothner writes:
[]
>>> be changed to make shape be a *one*-dimensional array - or better
>>> yet make it an unspecified opaque type.
[]
>> I would like to strongly second the suggestion to make the array
>> shape an unspecified opaque type.  A two-dimensional array may well
>
> Thirded.  Making an array shap an array seems to be confusing
> specification with implementation.  I think that you're really
> defining two types of objects in this SRFI, arrays *and* shapes.

Ok, I'm counting, but I plead not guilty. This SRFI wants to be a
sound basis for the kind of things that Noel Welsh has written about,
and for that, shapes should be easy to manipulate. There are tools to
take apart and put together list structure, and there will be for
arrays, so either of them is a good choice. - This isn't gratuitous
overspecification. I just didn't see the need for underspecification.

But I just realised that we can get there by providing things like
shape->array and shape->list. We get the best of both worlds.
--
Jussi