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