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

*To*: srfi-58@xxxxxxxxxxxxxxxxx*Subject*: Re: #\a octothorpe syntax vs SRFI 10*From*: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx>*Date*: Tue, 4 Jan 2005 13:42:08 -0800*Delivered-to*: srfi-58@xxxxxxxxxxxxxxxxx*In-reply-to*: <Pine.LNX.4.58.0501031619210.1697@xxxxxxxxxxxxxx>*Mail-followup-to*: srfi-58@xxxxxxxxxxxxxxxxx*References*: <Pine.LNX.4.44.0501021514050.31217-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0501031619210.1697@xxxxxxxxxxxxxx>*User-agent*: Mutt/1.4.1i

bear wrote: > I wanted an extremely terse syntax using the square brackets. It > turned out that nobody else wanted it, based on aesthetic objections. I too would like a terse vector/array syntax using square brackets. It's a very common notation for vectors and matrices, so it's a natural candidate for a Scheme external representation. However, too many Scheme implementations already use brackets as a synonym for parentheses. Bracket notation for vectors could've been a great language extension, but I suspect that it's too late for that now. Also, brackets have one major shortcoming (which the current SRFI 58 proposal shares): Since dimensions are inferred from the bracket contents, there's no way to represent arrays with a 0 dimension. For example, you can use SRFI 47 functions to create a 0x2x3 array: (MAKE-ARRAY '#() 0 2 3). However, there's no "natural" external representation for this array using brackets. Currently, SRFI 58 suffers from the same problem: Its syntax specifies rank explicitly but infers shape from the list decomposition. What should the Scheme writer use to represent that array? Is it an error? > You wanted an extremely verbose syntax using srfi-10. It turned out > that nobody else wanted it, based on aesthetic objections. I think #,(ARRAY ...) syntax is appropriate for some arrays. It would permit a good, general notation for arbitrary arrays, based on the MAKE-ARRAY function of SRFI 47. #,(ARRAY <prototype> (<dimensions>) (<element>...)opt) For example (using the common "brackets = parens" syntax for clarity): #,(ARRAY #() (2 2) [[a b] [c d]]) ; 2x2 heterogeneous array #,(ARRAY (AS32) (2 2) [[1 2] [3 4]]) ; 2x2 array of 32-bit fixnums #,(ARRAY #() (0 2 3)) ; zero-dimension array This allows the reader to use any SRFI 47 "prototype" function to specify array types. Thus, if a Scheme implementation adds new array types, they can simply add a new prototype generator. For example, an implementation can extend both MAKE-ARRAY and the reader syntax to support 36-bit integers simply by defining new "AS36" and "AU36" prototype functions. (MAKE-ARRAY (AS36 0) 1 2) => #,(ARRAY (AS36) (1 2) [[0 0]]) I don't think this is appropriate for hand-written, heterogeneous arrays, however. For those, I prefer something much terser. The proposed syntax is almost good enough; however, I would rather it specify the array /dimensions/ rather than rank. That's more consistent with existing extensions, like PLT's #n(...) syntax for vectors. Specifying the dimensions also permits a convenient shorthand for repetitive arrays: If there aren't enough elements for a dimension, simply repeat the last element. For example, #100(1) is shorthand for #(1 1 1 1 ... 1) in MzScheme, and #100() is shorthand for #(0 0 ... 0). A similar array syntax could use the analogous #A100x100() to get a very large zero matrix. -- Bradd W. Szonye http://www.szonye.com/bradd

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

**Re: #\a octothorpe syntax vs SRFI 10***From:*Aubrey Jaffer

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

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

- Prev by Date:
**Re: #\a octothorpe syntax vs SRFI 10** - Next by Date:
**Re: SRFI-10 syntax vs. #nA syntax** - Previous by thread:
**Re: #\a octothorpe syntax vs SRFI 10** - Next by thread:
**Re: #\a octothorpe syntax vs SRFI 10** - Index(es):