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.
Some email threads have continued after changes to SRFI-58 made them moot, which I have thus far not responded to. The appended addition to the Issues section (perhaps it should be in Rationale) addresses what I think were the main arguments in favor of SRFI-10 vs. #nA syntax. I know that I don't own all the best ideas, and have responded to and incorporated ideas from all the major contributors to these discussions. The current SRFI-58 bears little resemblance to my original proposal. The current state of SRFI-58 is a compromise. It is likely that none of us are completely happy with the choices (I prefer shorter prefixes), but SRFI-58 tries to balance the major concerns expressed by the participants. I hope we can feel some pride in having cooperatively forged an important piece of Scheme for the new millenium. -=-=-=-=- The use of SRFI-10 syntax for Arrays was discussed. The main arguments in favor of SRFI-10 were: SRFI-10 is for Scheme extensions, and thus appropriate for SRFI-47 arrays if they are not incorporated into R6RS. My efforts are directed toward making multidimensional arrays part of R6RS. Multidimensional arrays have been an integral part of computing since before electronic computers. A supposed general-purpose computer language without multidimensional arrays is an oxymoron. Literal arrays would not be used often enough to warrant a "#" syntax. Vector constants were thought useful enough that the "#(" syntax was appointed them. Many of the extant literal vectors (especially nested vectors) could be better expressed as arrays. Some literal nested lists would also be better suited to arrays. Bear@xxxxxxxxx gives some examples uses for literal arrays: Data tables for character properties. color palettes. Graphic sprites. Coordinate transformation matrices. cellular automata substructures. Default Window coordinate lists. Map data. Integrated-circuit diagrams. Alias tables for character names. Parallel Records. Tuple aggregates. Multi-Character tokens for protocol drivers. Image data. Compiler transition tables. Tax rate tables. Icons. Lists of countries, states, counties, and municipalities. Bus routes. Airline schedules. Cellular coverage areas. And the list goes on... Programs need to be able to dump this information to file in S-expressions and read it back. The proposed "#nA" syntax consumes too much of the precious "#" name-space. The claim is that SRFI-58 would consume ten characters (the ten decimal digits), far more than the single "(" used for vectors. But this accounting is disingenuous. It is highly unlikely that a one digit "#" code, say "#5" would be registered without including the other digits. If we consider "#" followed by digits to be a numeric argument to the character following, then only one letter, "A", worth of name-space has been allocated. "#nnn" followed by the letters B-Z and punctuation are all available. A choice must be made between SRFI-10 syntax and "#nA" syntax. I felt the reasons in support of the "#nA" syntax given in the Rationale were more compelling.