Let me first point out that you are _repeatedly_ answering points related to _operating_ on arrays, while I have not seen one argument for why _writing_literal_arrays_ should be made excessively concise except the nebulous aesthetics presented. If you want a comprehensive library for easily operating on arrays, go ahead, work on one, but that is entirely orthogonal to a literal array syntax, and it is becoming increasingly irritating to see people miss the points of all of my arguments just because they are thinking about operating on arrays instead of writing literal arrays. On Sun, 2 Jan 2005, bear wrote: > > - 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. This is a completely undefended assertion. You claim that arrays should have a succinct syntax without stating why that is so, and you again fall back to the nebulous aesthetics to claim that SRFI 10 'isn't good enough' for arrays. > > - 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. Sorry, I meant '...more frequently than arrays in Lisp's syntax.' (It was originally part of the first point, but, when splitting it off into a separate point, I forgot to include the 'in literal syntax' part.) > 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. Perhaps you could elaborate on this: I don't quite understand what you mean here. > 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... Great. So you've listed a lot of applications for arrays. Now answer the question I asked: how often do you find yourself in Scheme code wanting to write literal arrays by hand? Furthermore, what you have listed here tends to involve very large data sets, which completely dwarf the difference between '#nA:xxx(...)' and '#,(ARRAY n xxx ...)'. It is ludicrous that you find such a minute difference to be so significant. > Programs need to be able to dump > this information to file in S-expressions and read it back. Sure. What does this have to do with how convenient it is to write literal arrays in Scheme code? If the programs call READ & WRITE, you would never have to even write the #,(ARRAY ...) part! > > - 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. That is no argument. C has been in use for decades. That doesn't make it not kludgey or ad-hoc. I do not deny that the octothorpe has uses in syntax extension (for example, I recently submitted a SRFI for #; S-expression comments). However, the proposed array syntax is indeed ad-hoc. It is for the purpose of arrays and only arrays. It provides no benefit to anything other than arrays in Scheme. It is inconsistent with everything else in Scheme's syntax. > > - 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. It is very simple. You have the #, prefix and then a list. It is hardly much more verbose than the current array syntax; indeed, the difference in length is seven characters. The current array syntax, however, is complicated, specialized, encroaches on the #n octothorpe prefix space (which could easily be used for a number of different purposes), and is inconsistent with _every_other_element_ of Scheme's current syntax. It is even inconsistent with Common Lisp at this point, being incompatible with Common Lisp's #A syntax and assigning a very different meaning to the colon from that of Common Lisp. > > 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. You didn't answer my question here. You just said that interference isn't inherent. However, the SRFI states nothing about quasiquotation or syntax-rules; it is therefore reasonable to expect that none of the rules of quasiquotation or syntax-rules patterns or templates apply to arrays, since R5RS is very explicit about what they do apply to. There is _much_ more than just the reader to be extended if arrays are to be given better than a second-class status with respect to existing Scheme syntactic elements. Again, you have completely missed my point here by thinking about orthogonal issues that I'm not talking about.
