[SPAM] - Re: [GAP] Question about subprogram syntax - Email found in subject

[Robert Dewar]

Ted Baker wrote:

> A harder question from students is why Ada used parentheses for
> array indexing, as compared to [].  The two historical reasons I
> know are the Pascal precedent and the idea that an array index
> expression A(I) might be replaced later by a pointer-returning
> function call without recoding uses.  The latter works OK for
> expressions like A(I).Some_Field, where A could be an array of
> records or a function returning a pointer to a record.

It is less that you might change it, than that if you read
an array, the array is simply functioning as function, so why
should it read differently. The great majority of languages
follow this approach (i.e. the Fortran approach, as opposed
to the Algol approach).
> 
> On the other hand, Ada did not follow through in contexts where an
> expression is used as an L-value, including assignment statements
> and parameter passing. So, you can't write "A(I) := X;" if A is a
> function that returns a pointer. 

True

  That pretty well nullifies the
> supposed benefit of being able to interchange arrays and
> pointer-returning functions. 

As I said above, it is not interchanging that is the issue
(though in practice you may have situations where there are
far more reads than writes), as having a uniform reference
in the case where arrays are acting as functions.

> So, given arrays and functions are
> semantically distinct, why make this clear by a syntactic
> distinction?

> 
> A similar question arises as to the use of ()'s for aggregate
> expression versus {}'s, since it creates an ambiguity for
> aggregate values with a single element.

Not a serious ambiguity in practice, historically since {} are
national characters in ASCII, Ada wanted to stay away from these
characters.
> 
> These issues are all rather unimportant, though.  You can find just
> as many (more) syntactic blemishes in C and its children.

I don't see any of these as syntactic blemishes. Certainly the
lack of () in subprogram calls is 100% deliberate and far from
a blemish is considered the right choice.

Ditto for () for arrays.

For {} for aggregates, it is not clear that it makes sense to
use up a whole extra set of parentheses for this purpose. One
element aggregates are rare, and easily handled by going to
named notation which does not compromise readabiltiy (indeed
we usually prefer named notation anyay in aggregates)
> 
> --Ted
> 
> On Tue, Feb 21, 2006 at 10:36:30AM -0500, Peter C. Chapin wrote:
>> On Tue, 21 Feb 2006, Diego Alonso C?ceres wrote:
>>
>>> I've been teaching Ada for three years now and often my students make me 
>>> the same question: "Why don't parameter-less subprograms have empty 
>>> brackets like C or Java? The code would be easier to read and maintain. 
>>> It would be also possible to have a variable and a procedure with the 
>>> same name."
>>>
>>> I really don't what to answer because I think the same. Wasn't Ada 
>>> thought as "write once, read many times" or "Ada enhances readability"? 
>>> Why inherit this from Pascal?
>> I'm not an expert but my understanding was that this is considered a 
>> feature. The idea is that it is possible to replace a constant with a 
>> parameterless function without editing any code that uses that constant.
>>
>> 	A := B;
>>
>> B might be a value today, but a parameterless function tomorrow. This 
>> might be useful, for example, when it becomes necessary to do some 
>> significant computation to obtain the desired value.
>>
>> I don't know how often this actually comes up in the wild, though.
>>
>> Peter
> 
>> _______________________________________________
>> GAP mailing list
>> GAP at gnat.info
>> /no-more-mailman.html
>> To unsubscribe from this list, please contact the GAP GNAT Tracker administrator
>> within your organization.
> _______________________________________________
> GAP mailing list
> GAP at gnat.info
> /no-more-mailman.html
> To unsubscribe from this list, please contact the GAP GNAT Tracker administrator
> within your organization.