Re: #\a octothorpe syntax vs SRFI 10 bear 31 Dec 2004 08:38 UTC


On Thu, 30 Dec 2004 xxxxxx@autodrip.bloodandcoffee.net wrote:

>Before I get to responding to the content of this message, let me first
>state my position on square brackets for arrays.
>
>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.

But, that's more an opinion on the formulation of a
new lisp dialect, than on the extension of an existing
one.  You're probably right that there is sufficient
momentum now in the scheme community for conflating
parens and brackets that an opportunity to put brackets
to a different use has, in practical terms, probably
already been lost.

> 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.
 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.

> Although I don't have a better suggestion for the number syntax, I
> can't claim to like it as it is, either, and I think there are many
> who share my sentiments.  (I have certainly spoken to a number of
> them, and I recall a great deal of discussion over confusion in the
> number syntax on RRRS-authors in the past.  Bear seems to agree with
> me here.)

Yep. It needs to be combined with the exactness
information somehow.

				Bear