[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #\a octothorpe syntax vs SRFI 10
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
> > 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
> 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
> > 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.