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