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.
On Sun, 2 Jan 2005 campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote: >> My point is that the "nebulous aesthetic reasons expressed by >> Per Bothner" are in fact also expressed by everyone who has >> expressed an opinion in this matter except for yourself. > > I have spoken to a number of other people who either don't want an > array syntax at all, due to the amount by which it would unnecessarily > complicate Scheme's syntax, or don't want to see Scheme's syntax > complicated by anything more than SRFI 10. However, they're probably > not going to enter this discussion and point that out because there is > so much support on one side concentrated onto this discussion, So the lurkers support you in email? > - Lists are fundamental to Lisp syntax. Arrays are not. Operations > on arrays are unrelated to the syntax for literal arrays, so the > 'fundamentalness' of the concept of array has nothing to do with > the literal syntax. Arrays are damned useful, and being able to write them succintly is damned useful. It's true enough that scheme code is mostly lists, but that doesn't mean that a succinct syntax for arrays wouldn't be very useful, nor does it mean that SRFI-10 syntax is good enough for everything that isn't a list. > - Lists arise _vastly_ more frequently than arrays, and therefore > they certainly deserve a much more concise syntax than arrays. Different coders, different code. When I'm storing aggregations of things, I usually use vectors for access speed rather than lists. Doing so is extremely awkward in Scheme. I only use lists in code where they're either "the right thing" for that particular application, or I'm being deliberately lazy and not optimizing. I even go so far as to implement "closure" arrays for succinct reference and mutation instead of going through vector-ref and vector-set!. Not being able to write an external form for such gets in my way. How > often do you find yourself wanting to write a literal array, except > as the first argument to SRFI 47's MAKE-ARRAY? Geez, let me count the ways. 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. How the hell can you possibly write a program, beyond the high-school level, where you *DON'T* want to write a lot of literal arrays? > - One of the _hallmarks_ of Scheme is the simplicity & consistency of > its syntax. The more the syntax is extended in kludgey, ad-hoc > manners, the less consistency & simplicity you have. This is a Bad > Thing. Octothorpe syntax is neither klugey nor adhoc. It's been in use for decades in many different lisps. > - SRFI 10 provides a way to extend the syntax in a _consistent_ & > _simple_ manner. A consistent, not-very-simple, and unacceptably verbose manner for something as fundamental as arrays. > By the way, how does the proposed array syntax relate to quasiquotation > & syntax-rules? Perfectly. No one has suggested anything that would interfere with the quotation and quasiqotation marks quote, backquote, comma, or comma-at. > Is it just a portruding black mark in the syntax that > doesn't operate well with any other syntactic entity, & is therefore > offered only a _second-class_ status with respect to lists & vectors, > or do you have to extend a _lot_ more than just the reader in order to > support the syntax? No one has suggested anything that gives this charge any credence whatsoever. As I already said, no interference with quoting mechanisms can possibly emerge out of what has been proposed. > It looks a little silly to see you focus on a point that is hard to > defend in any way and completely ignore the rest of my message. If it makes you happier, now I've responded to these points. I skipped them in the first place because they are mostly spurious points IMO to start with and I didn't want to cause you further embarassment by pointing out how painfully obvious this is. But if you wanted to see them responded to, now you have. Bear