[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #\a octothorpe syntax vs SRFI 10
On Fri, 31 Dec 2004, bear wrote:
> On Thu, 30 Dec 2004 campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> >I think it would be much better to leave this SRFI as it is with regard
> >to parentheses versus square brackets and later have a SRFI, or perhaps
> >have it in R6RS, to make square brackets equivalent to parentheses.
> I think that squanders expressive power. Different
> tokens *should* mean different things, especially when
> the alternatives are cumbersome combinations of the
> by-now far overworked # character.
The octothorpe is intended to be overworked. For example, I quote
Richard Kelsey, one of the RnRS editors, from the SRFI 0 mailing list:
I do not think changes to the lexical syntax are a good idea. At a
minimum they should be restricted to the #... syntax.
SRFI 10 is intended to isolate changes to the lexical syntax further
and make them more consistent. It should be put to use, not completely
ignored just to make certain things more concise. One of the main
reasons that S-expressions are so successful in Lisp, as opposed to
M-expressions, is that they are simple & consistent. Breaking this
simplicity & consistency is not a good thing.
> > I'm opposed to any specialized square bracket syntax for arrays, and
> > very strongly so to such a complicated syntax as bear proposes.
> *sigh*. I thought I was proposing something simpler.
Perhaps I misunderstood, but, from the examples you gave, it looked
like the rank & array representation were put into a single token that
would have to be split, and spacing after the square bracket would
become significant to indicate that neither representation nor rank
are present. What would [1 2 3 4] represent? The same as #(2 3 4)?
How about [ 1 2 3 4]? #(1 2 3 4)? And [u16 1 2 3] vs [2 u16 1 2 3] vs
[2u16 1 2 3] vs [2 1 2 3] vs [ u16 1 2 3]? There are only subtle
syntactic distinctions between all of those, yet, if I understand your
proposed syntax correctly, they all have very different semantics. If
arrays are to have as nice a syntax as lists, as you suggest below,
there shouldn't be distinctions like those that aren't present in the
> Sorry if I missed the mark so badly. I think arrays
> are too fundamental to have any complicated or
> verbose syntax.
> Lispy lists are brilliant: open-paren, elements,
> close paren. I would love to be able to have
> something that simple and elegant for arrays.
> openbracket, elements, closebracket.
> The need to specify types for uniform arrays and
> ranks for arrays with multiple dimensions one of
> which is possibly zero complicates it, but the
> simplest case, IMO, should be as simple to express
> and as fundamental in syntax as a list.
What makes arrays so fundamental in syntax as to require a notation as
succinct as lists? Lisp syntax is not defined in terms of arrays: the
literal array syntax is only a minor convenience. There are many more
lists than arrays in a portion of code, typically.