Re: Why is it Called a Package?

[Paul Graham <pgraham@cadence.com>]

Pascal Obry wrote:
> I don't think we want that. A very nice consequence here is that you can
> easily change an abstraction from:
> 
>    package P is
>       Some_Value : array (1 .. 10) of Integer;
>       --  first quick implementation using basic array
>    end P;
> 
> to
> 
>    package P is
>       function Some_Value (N : in Positive) return Integer;
>       --  real implementation using a complex structure
>    end P;
> 
> (or the other way around) without modifying all client code.

What about:

    x := Some_Value(1 .. 3);

Changing the implementation from an array to a function is not so easy
here.

If for efficiency reasons you want to re-implement a function as an
array lookup, why not just write a public function as an interface to a
private array, then inline it?

I've always thought that using [] for indexing, slicing, and aggregates
would have made the language much simpler.  How many times have you Ada
experts had to explain to someone that (1) is not a legal array
aggregate?

Another thing that has always bothered me is the omission of parentheses
in a subprogram without arguments.  It results in some peculiar corner
cases in the language.  For instance, sometimes f.x means variable x
declared within function f, and sometimes it is a call to f returning a
record (or an access to record :-) with element x selected.  And I seem
to remember some ambiguities with attributes of sbprograms: is
f'some_attribute an attribute of the function f or of the value returned
by f.  Sure, the LRM has rules to resolve these ambiguities, but why
introduce the ambiguities in the first place?
 
Paul