Aubrey Jaffer wrote:

> Are there type specifiers in common between Scheme implementations?

Not to my knowledge.  But it might be worthwhile looking at Schemes
that focus on compilation, including Stalin, Bigloo, and Kawa.

Common Lisp is of course has a little mini-language.  The Emacs
cl package emulates a subset of the Common Lisp specifiers.

> Here is a plan which, using the delimiter you suggested, indicates
> signed vs. unsigned with - versus +:

I think that's a little too cute.  I think just a single 'u' prefix
is enough - and I don't think the hyphen is needed:
#nA:integer16 / #na:uinteger16.  Or just use the short "int"
instead of "integer" as in #nA:int16 / #nA:uint16.  That
abbrevation is consistent with C/C++'s stdint.h.  Using a
"u" prefix is also used in C#: ushort/ubyte etc.  (Note
I'd use the unabbreviated "integer" for unbounded integers.)

You could also use an "unsigned-" prefix as in #nA:unsigned-integer16
but that seems excessively verbose.

 > inexact         64.bit real                     #nA:real-64
 > inexact         32.bit real                     #nA:real-32

These aren't general real numbers, but "inexact real numbers
using a floating-point representation."  So use "float" rather
than "real".  So (assuming you drop the hyphen): #nA:float32
and #nA:float64.  Using "float" is also consistent with
Common Lisp type specifiers. (Common Lisp also has short-float,
single-float, double-float and long-float, though that level of
generality is less interesting these days.)

 > inexact         64.bit + 64.bit complex         #nA:complex-64
 > inexact         32.bit + 32.bit complex         #nA:complex-32

More specifically, they're complex numbers using a cartesian
representation of 2 floating-point parts.  I can certaily imagine
applications using complex arithmethc using integers coordinates.
So really "complex32" should be viewed as a short-hand for
"complex:float32".  Some systems might allow "complex:int16",
though I don't think we need to be this general for srfi-58.

>                 any (vector)                    #nA

I.e. #nA is short for #nA:object (or #nA:value).

>                 char (string)                   #nA:char

Is that 8-bit chars or implemention-defined chars?
One could have #nA:char8, #nA:char16 (Unicode), #nA:char32.
#nA:char would match an #nA:charW for some implementation-defined
W (which I guess might be 7 on a PDP-10 ...).

>                 boolean (bit-vector)            #nA:boolean

A boolean has values #f and #t.  A bit has values 0 or 1, and
is the same as a uint1.

> Another possibility is to use the word "natural" for nonnegative
> integers:

I don't think that's a good idea.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/