Re: Adding "()" operator to Ada 200X

["Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net>]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3EDE998D.3060701@attbi.com...
> I like the idea, but there are some practical problems.  First, a
> property of arrays in Ada, is that several attributes are currently
> predefined.  For Foo(Foo'First) to work correctly, you need user defined
> attributes.  Fortunately, the syntax is already "in there," but the
> attributes that can be defined would have to be extended, and there
> would probably be a rule required that when you defined an "()"
> function, the 'First, 'Last, 'Length, and 'Range attributes would become
> abstract and need to be overridden befor you could use the type.

In other words, why not allow the programmer to specify, in a standard
fashion, an iteration sheme (similar to the C++ iterators) for visiting each
index in a container object? Ada already has a lot of the intrasturcture
there, with the 'First, 'Last, 'Succ and 'Pred attributes. This idea has a
lot of merit, and should be explored further. It would be very nice if Ada0x
was designed so that a programmer could write

    for I in Foo'Range loop
        ...
    end loop;

for a user-defined array-like type.

> Also, I think that procedure "()" makes more sense, but that is just
> nomenclature.  What is not nomenclature is that Ada already allows
> functions as prefixes on the left-hand side of assignment statements!
> (The function has to return an access type, but from there on everything
> works like you would expect.)  So I recommend instead:
>
>      -- Function used to evaluate Source( Index )
>      function "()" ( Source : in Array_Like_Type;
>                      Index  : in Index_Type )
>         return Component_Type;
>
>      for Source'First use My_First;
>      for Source'Last use My_Last;
>      -- I think that allowing a definition of 'Range other than
>      -- Source'First..Source'Last would require too much invention.
>      -- Given that, Source'Length can be defined as
>      -- Index_Type'Pos(Source'Last) - Index_Type'Pos(Source'First) + 1.
>
>      -- function for assigning Value to Source( Index )
>      function "()" ( Source : in out Array_Like_Type;
>                      Index  : in     Index_Type)
>         return Component_Type'Access;
>
> Yes, that does though have the effect that for some types with packed
> representations you are not going to be able to define the second
> operation, so you must still use a procedure call to do the
> modification.  But it should work fine for sparse array implementations.

Granted, the function returning Component_Type'Access would work in many
cases, but I still think that the most general and powerful approach is to
have the "()" function and "():=" procedure. Consider an instantiation of
Ada.Direct_Io:

    type Element_Type is record ... end record;
    package Element_Io is new Ada.Direct_Io( Element_Type );
    use Element_Io;

    My_File : Element_Io.File_Type;

An open file of type Element_Io.File_Type can be thought of as an array of
objects of type Element_Type. In fact, one could view such a file as an
array of Element_Type objects that are stored in a random access file
instead of memory. Given this view, why not use array notation for the
handling the contents of this file? With the "()" and "():=" operators, we
could extend Ada.Direct_Io so that

    Read( File => My_File,
          Item => My_Element,
          From => Index );

could also be written (using the "()" function) as

    My_Element := My_File( Index );

Conversely, the "():=" procedure can be used to write to the file, i.e.
instead of writing

    Write( File => My_File,
           Item => My_Element,
           To   => Index );

the programmer would be able to write

    My_File( Index ) := My_Element;