Re: Proposed change to BC iterator parameters

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Jeffrey Carter <spam@spam.com> writes:

> amado.alves wrote:
> 
> > Strictly you don't need the limited formal for (unlimited) tagged or
> > class actuals. You need the limited formal for limited actuals,
> > whatever their class. Limitedness is completely orthogonal to
> > definiteness. I do like indefinite formals, but I pass well without
> > limited ones. Most limited formals I've seen in libraries are
> > accompanied by a formal assignment operation or some such, which
> > prety much defeats the purpose of their (formal) limitedness, i.e.
> > their logic is in clash with their definition.
> 
> The problem is that a generic formal part is a specification; it
> specifies what the generic needs, and the client must provide, for the
> generic to do its work. "Limited" implies 2 unrelated concepts: absence
> of assignment, and absence of predefined equality.

I agree with you here, but I can't get too excited about this particular
case, because similar problems exist for many Ada types.  Whenever you
declare a type, you get some predefined operations.  You can't say (for
an integer type), "I want predefined + but not predefined -".  It would
be nice to be able to express that, and as you point out, it would be
nice to be able to express "I want := but not predefined =".

You can use private types, and define + but not -, but then you can't
say "I want case_statements, integer literals, and +, but not - * /
etc".

Anyway, the key point of "limited" is that you can't copy things.  The
"=" issue is a more minor one, I think.

A much bigger problem with "limited" is that you can't have aggregates
and constructor functions, and you can't initialize objects.  As Robert
Eachus pointed out in some other thread, the ARG is actively working on
this.

> A non-limited formal type specifies that the generic needs to perform
> equality comparisons on values of the type, which is an error in
> specification. I know this seems a minor issue to many people, but
> precise specifications are essential to ensuring the correct usage of
> reusable components by their clients.

I agree, but I also want to be able to declare an integer type that can
only be incremented and not decremented or multiplied.  (And still allow
literals and case statements.)  It's a similar issue.

> This connection between assignment and equality may have made sense in
> Ada 83, where equality could only be defined for limited types, but
> seems an unnecessary restriction in Ada 95.

The Goodenough trick actually allowed declaring "=" on limited types in
Ada 83.

> In hindsight, it would have been better to eliminate the "limited"
> reserved word completely, and use instead
> 
> type T is private;
> -- Same as Ada's "limited private"
> 
> type T is private with ":=";
> -- Assignment defined; "=" not; no Ada equivalent
> 
> with the capability of defining "=" for either type.

Maybe.  How would you extend this to the integer-type issues I mentioned
above?  "Case statement" is not an operator...
Anyway, even if we restricted it to operators, it could get rather
verbose.  Saying "type T is range 1..10" is a concise way of defining
a bunch of operations, and if you don't want all of them, well, is that
good or bad?

Here, I think you're talking about regular private types in
packages (as opposed to generic formals).  One idea is to say:

    type T is private;
    function "="(X, Y: T) return Boolean is abstract;

Then clients can't call predefined "=".

(But predefined "=" reemerges in generics!  And records.)

I've also done things like this (in the visible part):

    type T is private;

    function Predefined_Equal(X, Y: T) return Boolean renames "=";
    -- For use only in the package body!

    function "="(X, Y: T) return Boolean is abstract;

Unfortunately, the Ada compiler does not understand the comment, "-- For
use only in the package body!".  You say above, ``with the capability of
defining "=" for either type.''  But it's not trivial to make that "="
be the predefined one.

- Bob