| Date: Thu, 6 Jan 2005 02:48:20 -0800
 | From: "Bradd W. Szonye" <xxxxxx@szonye.com>
 |
 | Aubrey Jaffer wrote:
 | > This approach combines rank, dimensions, and new floats.
 |
 | Initial impression: I love it!

Is it stunned silence from the others?  I have emailed the editor with
version 6.

 | > I punted rank-0 for now.
 |
 | Any particular reason why? It made sense.

It was 1:00am.  I restored them today.

 | > The prefix syntax is:
 | >
 | >   array-prefix :: rank `A' [ dimensions ] [ `:' type-specifier ] |
 | >                        `A' dimensions [ `:' type-specifier ]
 |
 | Would you mind terribly making the A optional in the second syntax?
 |
 |     array-prefix :: rank  `A'  [ dimensions ] [ `:' type-specifier ]
 |                   |      [`A']   dimensions   [ `:' type-specifier ]
 |
 | I realize that it complicates parsing a bit, but it also unifies

It took several hours to code, but it seems to work.

 | the dimension syntax with the #n(...) vector syntax of Common Lisp
 | and PLT Scheme.

Can you describe the PLT compatibility?

 | Don't forget to give semantics and examples for the shaped-array
 | syntax.  I don't particularly care whether you define the
 | repeat-fill rule; feel free to leave it for a later SRFI if you
 | don't want to write it up.

Do whole rows, planes, etc also repeat?

 | >   dimensions :: dimension | dimensions `*' dimension
 |
 | Anybody feel strongly about "*" vs "x" for the bound separator? I
 | prefer "x" because it makes the digits stand out more in my editor,
 | but that may be just a personal/old-age/font thing. Here are some
 | samples:
 |
 |     A1. #A2*3*4(...)      X1. #A2x3x4(...)      T1. #A2×3×4(...)
 |
 |     A2. #A20*30*40(...)   X2. #A20x30x40(...)   T2. #A20×30×40(...)
 |
 | Hm, strange. A2 and X1 are quite readable on my screen, but A1 and
 | X2 blur together, making it hard to distinguish the numbers at a
 | glance. T1 and T2 are also good, but they use U+00D7 (the 'times'
 | symbol) which won't be universally available on Scheme systems.

I don't like x because it looks like mistyped hex numbers (#x33)

 | > prototype                                                   type
 | > procedure   exactness   element type			    specifier
 | > =========   =========   ============			    =========
 | > vector      any
 | > A:floc128b  inexact     128.bit binary flonum complex       floc128b
 | > A:floc64b   inexact     64.bit binary flonum complex        floc64b
 | > A:floc32b   inexact     32.bit binary flonum complex        floc32b
 | > A:floc16b   inexact     16.bit binary flonum complex        floc16b
 | > A:flor128b  inexact     128.bit binary flonum real          flor128b
 | > A:flor64b   inexact     64.bit binary flonum real           flor64b
 | > A:flor32b   inexact     32.bit binary flonum real           flor32b
 | > A:flor16b   inexact     16.bit binary flonum real           flor16b
 | > A:flor128d  exact       128.bit decimal flonum real         flor128d
 | > A:flor64d   exact       64.bit decimal flonum real          flor64d
 | > A:flor32d   exact       32.bit decimal flonum real          flor32d
 | > A:fixz64    exact       64.bit binary fixnum                fixz64b
 | > A:fixz32    exact       32.bit binary fixnum                fixz32b
 | > A:fixz16    exact       16.bit binary fixnum                fixz16b
 | > A:fixz8     exact       8.bit binary fixnum                 fixz8b
 | > A:fixn64    exact       64.bit nonnegative binary fixnum    fixn64b
 | > A:fixn32    exact       32.bit nonnegative binary fixnum    fixn32b
 | > A:fixn16    exact       16.bit nonnegative binary fixnum    fixn16b
 | > A:fixn8     exact       8.bit nonnegative binary fixnum     fixn8b
 | > A:bool                  boolean                             bool
 |
 | That covers all of the basic types.  Only binaryx is missing, and I
 | suspect that it'll be a common extension to the SRFI.  One problem
 | with adding x86 binaryx is that I don't know whether you should
 | call it an 80-bit type or a 96-bit type.  I don't mind if you punt
 | on it.

I think you will find that vectorized instructions don't pack
non-power-of-2 bit widths.  Breaking operands over cache-line
boundaries is a huge hassle for hardware.

So the 80-bit and 96-bit are likely stored into 128 bits.  We might as
well call them 128b.  This text I added describes how sizes are
chosen:

  Implementations are required to accept all of the type denotations.
  Uniform types of matching sizes which the platform supports will be
  used; the others will be represented as the next larger format of
  the same type implemented.  If there is no larger format of the same
  type and there is a bignum format for that element type, then the
  array format defaults to vector; otherwise the largest uniform
  format of that type is used.

 | No fixq arrays for rational numbers?  C'mon, you know you want to!

Although the syntax could easily specify arbitrary precisions, the
prototype functions would need to take extra arguments.  Should the
precision be specified as total bits and fractional bits; or integral
bits and fractional bits?

 | Thanks for shortening "boolean" to "bool."

All the type name roots are now 4 characters.

 | What should systems do if they don't provide a 128-bit fixnum?
 | 16-bit fixnums are OK, because you can fake them with a larger
 | type, but there's no good way to get 128-bit floats on an
 | x86. Please don't /drop/ the 128-bit type, but please do specify
 | what to do about it.

The text above does.  If you don't have 128-bit flonums, use the
largest flonums you have.

 | Everything else looks good.
 |
 | Joke: This draft is even more compatible with Common Lisp than the
 | original proposal, because it gives you the kitchen sink too!

It is the Swiss-army-knife of array syntax.  I hope the R6RS editors
are okay with that.