[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: per@xxxxxxxxxxx*Subject*: Re: #\a octothorpe syntax vs SRFI 10*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Fri, 31 Dec 2004 23:17:47 -0500 (EST)*Cc*: campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx, srfi-58@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-58@xxxxxxxxxxxxxxxxx*In-reply-to*: <41D5A36E.30205@xxxxxxxxxxx> (message from Per Bothner on Fri, 31 Dec 2004 11:07:26 -0800)*References*: <Pine.LNX.4.44.0412311032200.20579-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <41D5A36E.30205@xxxxxxxxxxx>

| 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. Yes. | 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. Amen! | 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 | context). | | 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? Which 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 numerical terminology. 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 integers: 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

**Follow-Ups**:**Re: #\a octothorpe syntax vs SRFI 10***From:*bear

**Re: #\a octothorpe syntax vs SRFI 10***From:*Per Bothner

**References**:**Re: #\a octothorpe syntax vs SRFI 10***From:*campbell

**Re: #\a octothorpe syntax vs SRFI 10***From:*Per Bothner

- Prev by Date:
**Re: precision of signed integers** - Next by Date:
**Re: #\a octothorpe syntax vs SRFI 10** - Previous by thread:
**Re: #\a octothorpe syntax vs SRFI 10** - Next by thread:
**Re: #\a octothorpe syntax vs SRFI 10** - Index(es):