Subscript brackets

Subscript brackets

[Michael Talbot-Wilson]

Are there any plans to convert from parentheses to square brackets
for array subscripts in Ada?

Maybe this is a minor point, and I guess BASIC, PL/I and FORTRAN
programmers think it's better as it is.  (And I guess the use of
parentheses reflects that Ada's heritage is in those languages.)

But C, Pascal, Modula-2 and (if there are any left alive) ALGOL
programmers feel the reverse.  Minor or not, it is a big psycho-
logical hurdle to adjust to something inferior (and even the FAQ
concedes that this is a broken feature) in the name of doing things
better.

A preprocessor which converted just these parentheses to brackets
and left non-array-subscript parentheses alone would allow
existing source to be compiled.  And (I guess) remove the ambiguities
of parsing this feature from the compiler, allowing its cost to
be more clearly seen.

It there any intention of doing this?  Is there any suggested date
when it might happen?  I think some people who would like to convert
to or start working in Ada would like a date to aim at, supposing it
is ever going to happen.

-- Mike

Re: Subscript brackets

[Robert I. Eachus]

In article <4m515d$pok@calypso.bns.com.au> mike@calypso.bns.com.au (Michael Talbot-Wilson) writes:

  > Are there any plans to convert from parentheses to square brackets
  > for array subscripts in Ada?

   Not in this millenium....

  > Maybe this is a minor point, and I guess BASIC, PL/I and FORTRAN
  > programmers think it's better as it is.  (And I guess the use of
  > parentheses reflects that Ada's heritage is in those languages.)

   No, it reflects a unification between tabular data and functions
which is totally intentional.  I often prototype with many complex
options being tables in the prototype, and functions in the final
product:

    type Message_Length is array (Message_Type) of Integer;
     ...
    
    function Message_Length(M: in Message_Type) return Integer;

    This allows the message lengths to be changed in a table without
recompiling things.

  > But C, Pascal, Modula-2 and (if there are any left alive) ALGOL
  > programmers feel the reverse.  Minor or not, it is a big psycho-
  > logical hurdle to adjust to something inferior (and even the FAQ
  > concedes that this is a broken feature) in the name of doing
  > things better.

  > A preprocessor which converted just these parentheses to brackets
  > and left non-array-subscript parentheses alone would allow
  > existing source to be compiled.  And (I guess) remove the ambiguities
  > of parsing this feature from the compiler, allowing its cost to
  > be more clearly seen.

   I have a better idea...write a preprocessor to replace square
brackets with angle brackets, and you will have no problem using
existing Ada compilers.  I could probably write a very good
preprocessor of this form in a couple hours.

   However, if you decide to do realistic error checking, you have a
lot of decisions to make.  Do all attributes use parentheses, or just
those which are functions?  If A'First[1] requires brackets, what
about A'Range(1)?  You get the picutre.

  > It there any intention of doing this?  Is there any suggested date
  > when it might happen?  I think some people who would like to convert
  > to or start working in Ada would like a date to aim at, supposing it
  > is ever going to happen.

  I doubt it.  It could be done, but it would be a rough haul for very
little gain.


    
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Subscript brackets

[Robert Dewar]

Mike said

"Are there any plans to convert from parentheses to square brackets
for array subscripts in Ada?"

Apart from the fact that such a change would be a grautitous an
serious incompatibility at this stage, it is in fact considered
desirable to use parentheses for arrays, and there is no plan at
all to change, nor would such a suggestion be seriously entertained.

The argument in favor of parentheses is one of uniformity of reference.
An array is, from a mathematical point of view, simply a function.
There is a special way of implementing the function efficiently, but
since at the abstract level it is a function, it should have the
same syntax as a function.

Of course there is nothing to stop an implementation accepting sqaure
bracets as an alternative representation for normal parens (GNAT does
so with an error message :-)

Finally one cannot take seriously the suggestoni that this is a major
barrier to the use of Ada. Ada has, at this level, a quite diferent
syntax from the other languages you mention, and there is no intrinsic
merit in trying to mirror some other language for the sake of doing so.
Indeed even from a pragmatic point of view, such a change makes no sense.
You may make an Algol programmer epsilon more comfortable, but you would
make a Fortran or COBOL programmer epsilon less comfortable.

Re: Subscript brackets

[Tarjei Jensen]

>In article <dewar.831031371@schonberg> Robert Dewar writes:
>   The argument in favor of parentheses is one of uniformity of reference.
>   An array is, from a mathematical point of view, simply a function.
>   There is a special way of implementing the function efficiently, but
>   since at the abstract level it is a function, it should have the
>   same syntax as a function.
>

Which means that once again one has fallen into the trap of using something
cute instead of waking up to the realities that as far as the programmer is
concerned source code is text and not a mathematical expression.

As far as I am concerned the "orthogonality" is far fetched and an excellent
example of how to carry things too far.

In my opinion one throws away an enhancement to readability by not using square
braces. They would be useful in other situations as well. I prefer array[ n ]
to array( n ) and record = [ field1, field2 ] to record = ( field1, field2 ).

Greetings,
 
--
// Tarjei T. Jensen 
//    tarjeij@ulrik.uio.no || fax +47 51664292  || voice +47 51 85 87 39
//   Support you local rescue centre: GET LOST!
// Working, but not speaking for the Norwegian Hydrographic Service.

Re: Subscript brackets

[Robert A Duff]

In article <4m515d$pok@calypso.bns.com.au>,
Michael Talbot-Wilson <mike@calypso.bns.com.au> wrote:
>Are there any plans to convert from parentheses to square brackets
>for array subscripts in Ada?

No way.

I like square brackets for array indexing, too.  I understand the
uniform-reference argument that Roberts Eachus and Dewar gave, but I
don't buy it.  The semantics of arrays and functions are different
enough, in my opinion, that using the same notation is a confusion,
IMHO.  And, when combined with the fact that parameterless function
calls don't have parens, it adds a big chunk of complexity to Ada
compilers, for little benefit.

Historically, I believe the uniform-reference argument was *part* of the
original reason for not using square brackets.  Another part was that
the early requirements documents for Ada stated that the character set
used had to be restricted, so that it could be used on things like
teletype machines.

I also think that square brackets, or *some* other notation, should have
been used for aggregates.  This would solve the problem that you can't
write a positional array aggregate with one element, in Ada, because it
would be confused with a parenthesized expression.  You also can't write
a zero-element positional array aggregate, which is another design flaw.

>Maybe this is a minor point, ...

Yes, it's a minor point, which is why it's not likely to change.

>A preprocessor which converted just these parentheses to brackets
>and left non-array-subscript parentheses alone would allow
>existing source to be compiled.  And (I guess) remove the ambiguities
>of parsing this feature from the compiler, allowing its cost to
>be more clearly seen.

I'm not sure what you mean, here.  The preprocessor reads standard Ada,
and outputs square brackets instead?  Such a preprocessor needs to do
overload resolution, which makes it approximately as complex as the
front end of an Ada compiler.  Seems like a lot of trouble for a "minor
point".

>It there any intention of doing this?  Is there any suggested date
>when it might happen?  I think some people who would like to convert
>to or start working in Ada would like a date to aim at, supposing it
>is ever going to happen.

I doubt if a lot of people who would like to use Ada are holding off
because of this minor syntactic point.

- Bob

Re: Subscript brackets

[Robert Dewar]

"Historically, I believe the uniform-reference argument was *part* of the
original reason for not using square brackets.  Another part was that
the early requirements documents for Ada stated that the character set
used had to be restricted, so that it could be used on things like
teletype machines."

Hello, I am an old teletype machine and mostly I sleep these days, but
one of my grandchildren (a superduper 300MHz workstation) woke me up
to show me the above quote. I wish you all to know that my share
of printing square brackes is behind me now, and my square bracket
keys, like all the other keys are a bit warn, but you could not possibly
mistake them even now for round parenes.

Now it is certainly true that that idiot across the street, the O29 
keypunch, has no square brackets, but you can't blame him too much,
he works for a company whose wondrous EBCDIC code either does not
include square bracket, or, depending on which page you read, puts
them in four different places in the code chart.