[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #\a octothorpe syntax vs SRFI 10
| Date: Fri, 31 Dec 2004 11:07:26 -0800
| From: Per Bothner <per@xxxxxxxxxxx>
| campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
| > On Thu, 30 Dec 2004, Per Bothner wrote:
| >>Array syntax should be compatible with Common Lisp's notation.
| >>Anything else requires a *really* strong justification.
| > Why doesn't Common Lisp's notation require just as strong of a
| > justification?
| Scheme's syntax is in general very close to Common Lisp's. This
| includes the notation for vectors. The Common Lisp vector and
| array notations are related, which makes sense since a vector is a
| special case of an array. The Scheme vector notation is the same
| as the Common Lisp vector notation. Having a completely different
| array notation would reduce interoperability and skill
| transferability for no good reason.
| I'm also concerned about stylistic compatibility within Scheme
| itself, regardless of Common Lisp. Requiring SRFI-10 notation for
| arrays but not for vectors, is really ugly and makes arrays into
| second-class constructs, which is unfortunate given that vectors
| are just a special case of arrays.
| Some Scheme implementations may already support Common Lisp's #A syntax.
| (I thought Kawa did, but I guess I never got around to implementing it.)
SCM does. Guile does #<n>((...)); they lost the A.
| What I am requesting is that "array type specifiers" should be
| written to use "element type names", not "array type names", and
| that element type names should be identifiers that would make sense
| it somebody *does* do type specifiers. I.e. instead of "aint32" or
| "as32" use "int32" or (for example) "array:int32" (depending on
| Some Scheme implementations *do* support type specifiers, and of
| those specifiers some are also representation specifiers; please
| don't invent an array type syntax incompatible with type specifiers
| for declarations.
Are there type specifiers in common between Scheme implementations?
For Scheme type-specifiers, most of what Google found are for foreign
datatypes. The treatment of signed versus unsigned involves either
the word "unsigned" and its absence; or the letters S and U.
Having complex arrays and bit-arrays, SRFI-47 and SRFI-58 were not
motivated by foreign-language interfaces. I will replace the foreign
Here is a plan which, using the delimiter you suggested, indicates
signed vs. unsigned with - versus +:
exactness element type prefix
========= ============ ======
any (vector) #nA
inexact 64.bit + 64.bit complex #nA:complex-64
inexact 32.bit + 32.bit complex #nA:complex-32
inexact 64.bit real #nA:real-64
inexact 32.bit real #nA:real-32
exact 64.bit integer #nA:integer-64
exact 32.bit integer #nA:integer-32
exact 16.bit integer #nA:integer-16
exact 8.bit integer #nA:integer-8
exact 64.bit nonnegative integer #nA:integer+64
exact 32.bit nonnegative integer #nA:integer+32
exact 16.bit nonnegative integer #nA:integer+16
exact 8.bit nonnegative integer #nA:integer+8
char (string) #nA:char
boolean (bit-vector) #nA:boolean
Another possibility is to use the word "natural" for nonnegative
exact 64.bit natural-number #nA:natural-64
exact 32.bit natural-number #nA:natural-32
exact 16.bit natural-number #nA:natural-16
exact 8.bit natural-number #nA:natural-8