Reemergence of predefined equality operator...

Reemergence of predefined equality operator...

[Dale Stanbrough]

I was demonstrating what i thought would be the reemergence of
the predefined equality operator by doing...

   type text is... (record with length & chars, like bounded string)
   function "=" (a, b : text) return boolean;


and


   generic
      type element is private;
      with function "=" (a, b : element) return boolean is <>;
   package...

and after instantiating the generic with type text it kept calling
the "=" defined for type text.

I thought Ada (through a bad design decision) said that it should call
the predefined "=" opertor in this instance. Has this been changed,
or do have I misunderstood the problem?

Dale

Re: Reemergence of predefined equality operator...

[Robert A Duff]

Dale Stanbrough <dstanbro@bigpond.net.au> writes:

> I was demonstrating what i thought would be the reemergence of
> the predefined equality operator by doing...
> 
>    type text is... (record with length & chars, like bounded string)
>    function "=" (a, b : text) return boolean;
> 
> 
> and
> 
> 
>    generic
>       type element is private;
>       with function "=" (a, b : element) return boolean is <>;
>    package...
> 
> and after instantiating the generic with type text it kept calling
> the "=" defined for type text.
> 
> I thought Ada (through a bad design decision) said that it should call
> the predefined "=" opertor in this instance. Has this been changed,
> or do have I misunderstood the problem?

You've misunderstood the problem.  ;-)

Above, you passed in a formal "=" explicitly.  The "is <>" means that
the default is to pass in whatever "=" happens to be visible at the
place of the instantiaation (and has the right profile types).  That is
probably the user-defined "=" that you wanted.  In that case, the
"problem" does not occur.

The "problem" is when you leave out the explicit ``with function
"="...''.  Then type "element" has a predefined "=" (because it's
private, not limited private).  In that case, the predefined "=" of the
actual type "reemerges".  In other words, if you instantiate with
Element => T, and T has a primitive user-defined "=", the instance will
call the predefined "=" rather than the user-defined one.

If you wanted to drive a stake through the heart of the predefined "="
by declaring a user-defined "=", so that every time objects of type T
are compared for equality it will call the user-defined "=", then you
lose -- if you pass T to a generic or wrap T in a record, the predefined
"=" reemerges (rises from the dead).

For "=", this seems "obviously" wrong.  But as I pointed out elsewhere,
the situation for other operators (eg, "mod"), is not so obvious.
Even if the language were changed, or even if Text_IO.Integer_IO took
"mod" as an "is <>" parameter as above, it's not clear (to me) what the
right answer is.

- Bob

Re: Reemergence of predefined equality operator...

[Vincent Marciante]

Robert A Duff wrote:

<snip> 
 
> If you wanted to drive a stake through the heart of the predefined "="
> by declaring a user-defined "=", so that every time objects of type T
> are compared for equality it will call the user-defined "=", then you
> lose -- if you pass T to a generic or wrap T in a record, the predefined
> "=" reemerges (rises from the dead).
> 
> For "=", this seems "obviously" wrong.  But as I pointed out elsewhere,
> the situation for other operators (eg, "mod"), is not so obvious.
> Even if the language were changed, or even if Text_IO.Integer_IO took
> "mod" as an "is <>" parameter as above, it's not clear (to me) what the
> right answer is.

The crux of the problem in this specific case (generic private types) 
seems to me to be _not_ reemergence but actually the new (Ada 95)
permission
to override predefied "=".  (Allowing the definition of "=" with a 
non-boolean result does not seem to be a problem.)

If overriding of predefined "=" was disallowed in the future (not
practical?) wouldn't that solve the problem well?   Is that really
really not practical?

Vincent Marciante

Re: Reemergence of predefined equality operator...

[Robert Dewar]

Vincent Marciante <marciant_remove@earthlink.net> wrote in message news:<3D488F3D.6186@earthlink.net>...
> If overriding of predefined "=" was disallowed in the 
> future (not practical?) wouldn't that solve the problem 
> well?   Is that really really not practical?

Of course that's not practical. Do you really think vendors
would pay any attention if the Ada design went berserk and
started adding gratuitous non-upward compatible changes?
Remember that it is possible to redefine "=" in Ada 83
as well.

A criterion for Ada 95 was no non-upwards compatible changes (unless a
VERY good argument could be given,
e.g. optional package bodies and the (<>) generic
stuff, where Ada 83 was clearly broken).

That criterion has to be applied even more strongly
for any future revisions to Ada. 

One thing to be careful of is that current proposals for
revisions to Ada are coming mostly from hobbyists and language
designers, not from actual users writing large
application programs. That means one needs to be even more
cautious in countenancing changes.

Actually in practice, I think any new "Ada0X" will be no
more than a list of suggestions for enhancements and new
ideas. I think there will be almost no commercial pressure
to implement such a new standard in some validated form
for the forseeable future (after all, look how long it took
for the C standard to take hold).

Re: Reemergence of predefined equality operator...

[Vincent Marciante]

Robert Dewar wrote:
> 
> Vincent Marciante <marciant_remove@earthlink.net> wrote in message news:<3D488F3D.6186@earthlink.net>...
> > If overriding of predefined "=" was disallowed in the
> > future (not practical?) wouldn't that solve the problem
> > well?   Is that really really not practical?
> 
> Of course that's not practical. 

Yes, of course.

<snip>

> Remember that it is possible to redefine "=" in Ada 83
> as well.

Only for limitted types (except for the trick that has been 
mentioned occasionally) right?  By the way, can you describe 
the trick or refer me to more info about it?

Re: Reemergence of predefined equality operator...

[Robert A Duff]

Vincent Marciante <marciant_remove@earthlink.net> writes:

> Only for limitted types (except for the trick that has been 
> mentioned occasionally) right?  By the way, can you describe 
> the trick or refer me to more info about it?

The trick is to have a generic formal limited private type,
and derive from that, and define "=" on the derived type.
Then instantiate with a non-limited type.

I believe this trick was first noticed by John Goodenough.

- Bob

Re: Reemergence of predefined equality operator...

[Dale Stanbrough]

Robert A Duff wrote:

> For "=", this seems "obviously" wrong.  But as I pointed out elsewhere,
> the situation for other operators (eg, "mod"), is not so obvious.
> Even if the language were changed, or even if Text_IO.Integer_IO took
> "mod" as an "is <>" parameter as above, it's not clear (to me) what the
> right answer is.

Wouldn't it be appropriate for Text_IO.Integer_IO, if it wants to be
sure of the mod operator it is using, to simply specify it?

E.g.
   
   procedure put (item : natural) is
      zero_char : constant := character'pos ('0');
   begin
      if item < 10 then
         put (character'val (item + zero_char));
      else
         put (item / 10);
         put (Standard."mod" (item, 10));
      end if;
   end;


That way if a new mod was imported via a generic parameter it 
simply wouldn't be used in this case.

Dale

Re: Reemergence of predefined equality operator...

[Robert A Duff]

Dale Stanbrough <dstanbro@bigpond.net.au> writes:

> Wouldn't it be appropriate for Text_IO.Integer_IO, if it wants to be
> sure of the mod operator it is using, to simply specify it?

Well, maybe, but I don't understand your example below.
The parameter of Put is a generic formal type, but you have
written Natural.  If it were Natural, then the reemergence issue
would not arise, and ``item mod 10'' means exactly the same as
``Standard."mod" (item, 10)''.  If it's a generic formal type,
then ``Standard."mod" (item, 10)'' would be illegal.  Either way,
I don't see the point of Standard."mod".

Also, you didn't do anything special for the "<", "+", and "/"
shown below, which have the same issue.

>    procedure put (item : natural) is
>       zero_char : constant := character'pos ('0');
>    begin
>       if item < 10 then
>          put (character'val (item + zero_char));
>       else
>          put (item / 10);
>          put (Standard."mod" (item, 10));
>       end if;
>    end;
> 
> That way if a new mod was imported via a generic parameter it 
> simply wouldn't be used in this case.

A new "mod" is *not* imported by a generic parameter.  The generic
package we're talking about takes the type, and the "mod" we're talking
about is simply the primitive "mod" for that type.  The question is,
inside the generic, should the primitive "mod" be user-defined
if the actual type has one?

> Dale

- Bob