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

This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.

*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):