[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #\a octothorpe syntax vs SRFI 10
On Sun, 2 Jan 2005, bear wrote:
> On Sat, 1 Jan 2005 campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> >On Sat, 1 Jan 2005, bear wrote:
> >> Arrays, properly supported, are not an extension. They're a core language
> >> feature like lists. They deserve their own syntax.
> > There is very little reason, beyond the nebulous
> > aesthetics that Per Bothner has expressed, to give them as special
> > syntax as lists are given.
> Okay, I want to point a few things out:
> [snip a bunch of messages, all of which I have already responded to]
> 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, it has
been a fairly long discussion by now that is not as easy to follow as
many would desire in order for them to enter it, and you would probably
ignore them anyway, just as you ignored the remainder of my message.
Here, I'll restate the points that you snipped, in a nice, clear list:
- 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.
- Lists arise _vastly_ more frequently than arrays, and therefore
they certainly deserve a much more concise syntax than arrays. How
often do you find yourself wanting to write a literal array, except
as the first argument to SRFI 47's MAKE-ARRAY?
- 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
- SRFI 10 provides a way to extend the syntax in a _consistent_ &
By the way, how does the proposed array syntax relate to quasiquotation
& syntax-rules? 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?
> So it looks a little silly to see you disparaging this opinion
> as the "nebulous aesthetic concern" of a single person - unless
> the single person you're talking about is yourself.
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.