On Sun, 2 Jan 2005 xxxxxx@autodrip.bloodandcoffee.net 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