Redefined "=" = generic disaster?

Redefined "=" = generic disaster?

[Vincent Marciante]

In Ada 83, one could specify/declare a generic formal private type and
then compare objects of that type without any problems - the only
instance where the concept of equality could be changed is for limited
private types.  So in effect, when one specified a private formal one
got the equality operator as a side effect and could utilize it without
any surprises.

Now however, in Ada 95, one _can_ redefine equality for "any type at
all".  Therefore, all generic unit code that previously "safely"
utilized "=" of a generic formal nonlimitted type may now cause
unexpected results.

For example if one now has an Ada 95 abstraction such as 

package Ada_95_Assignable_Thing is
     type Thing is private; 
     function "=" (Left, Right : Thing) return Boolean;
     ...  
end; 

One might expect to be able to use it when instantiating an old, fully
tested generic unit that was written in Ada 83 and that compiles cleanly
without any warnings and that has a spec such as 

generic
    type Something is private;
package Ada_83_Abstract_Data_Type is
    type ADT is private;
    ...
    function Is_Equal (L,R: ADT) return Boolean;
end;
package body Ada_83_Abstract_Data_Type is
    ...
    function Is_Equal (L,R: ADT) return Boolean;
    begin
        return L = R;
    end;
end;

package Instance_Ada_83_ADT is 
    new Ada_83_Abstract_Data_Type(Ada_95_Assignable_Thing);


My point is that, because everything could compile correctly, one would
expect that the primative "=" for type "Thing" would be utilized in
"Is_Equal" but it is not.  Yes, I know that people can "expect" may
things that "clear" ;) should not be expected but isn't this as bad as
the problem with unconstrained formal types that was fixed in Ada 95? 
The problem here is (said with a Brooklyn accent;) "The spec asked for a
private type, so thats what I gave it but the program don't work????"

Aspects (or all?) of this have been discuss under previous threads
regarding "reemergence of predefined operators" and the lawyers have
stated that is good reason for it but could find discussion specifically
about "=".   Would not having "=" reemerge be bad?  If only "=" did not
reemerge then this possibly wide spread problem with old code would not
be an issue.

BTW, I not interested in arguments that the old Ada 83 code was actually
incorrect when it first written.  I am interested in finding out wats to
update it so that it works as one would expect ;) in Ada 95.   All I can
think of now is ethier add 

  function "=" (L,R: Private_Type) return Boolean is "="; 

to all generic parts of the old code for all formal private types in the
generic part or examine all of the bodies and search for usage of "=" of
the private type and then add

  function "=" (L,R: Private_Type) return Boolean; 

to their generic part.

So, after all of this, what is the best way to fix the old code?

Vinny

P.S. Wow its late, I hope (all/most;) of the above makes sense!

Re: Redefined "=" = generic disaster?

[Jeff Carter]

Vincent Marciante wrote:
> generic
>     type Something is private;
> package Ada_83_Abstract_Data_Type is
>     type ADT is private;
>     ...
>     function Is_Equal (L,R: ADT) return Boolean;
> end;
> package body Ada_83_Abstract_Data_Type is
>     ...
>     function Is_Equal (L,R: ADT) return Boolean;
>     begin
>         return L = R;
>     end;
> end;

This is not valid Ada 83. Assuming we add a private part to the spec and
replace the ";" after "Boolean" with " is" in the body, you are invoking
the predefined "=" on the local type ADT, not the generic formal type
Something. Since we don't know the full definition of ADT, we don't know
what this has to do with "=" for Something. If ADT is a composite type
with one or more components of type Something, then "=" for ADT is
defined (at least partly) in terms of the predefined "=" for Something.

> BTW, I not interested in arguments that the old Ada 83 code was actually
> incorrect when it first written.  I am interested in finding out wats to
> update it so that it works as one would expect ;) in Ada 95.

Any generic that uses "=" for a generic formal type should explicitly
import "=" for the type:

generic -- Some_Package
   type T is private;
   with function "=" (Left : T; Right : T) return Boolean is <>;
package Some_Package is
...

> think of now is ethier add
> 
>   function "=" (L,R: Private_Type) return Boolean is "=";

The construct

   is "="

on a generic formal function (note that you need "with" before
"function") refers to a function named "=" that is visible when the
generic is compiled. Such a function is unlikely to exist for a generic
formal private type. To refer to a function "=" that is visible when the
generic is instantiated, which is probably what you wanted, use

   is <>

instead.

> P.S. Wow its late, I hope (all/most;) of the above makes sense!

Possibly.

-- 
Jeff Carter
"I waggle my private parts at your aunties."
Monty Python & the Holy Grail

Re: Redefined "=" = generic disaster?

[Vincent Marciante]

Jeff Carter wrote:
> 
> Vincent Marciante wrote:
> > generic
> >     type Something is private;
> > package Ada_83_Abstract_Data_Type is
> >     type ADT is private;
> >     ...
> >     function Is_Equal (L,R: ADT) return Boolean;

    private
        type ADT is ... composite type containing "Something"

> > end;
> > package body Ada_83_Abstract_Data_Type is
> >     ...
> >     function Is_Equal (L,R: ADT) return Boolean;

        function Is_Equal (L,R: ADT) return Boolean is

> >     begin
> >         return L = R;
            return <something part of L> = <something part of R>;

> >     end;
> > end;
> 
> This is not valid Ada 83. Assuming we add a private part to the spec and
> replace the ";" after "Boolean" with " is" in the body, you are invoking
> the predefined "=" on the local type ADT, not the generic formal type
> Something. Since we don't know the full definition of ADT, we don't know
> what this has to do with "=" for Something. If ADT is a composite type
> with one or more components of type Something, then "=" for ADT is
> defined (at least partly) in terms of the predefined "=" for Something.

Yes!! Your assuming was much better than my typing ;)  (Very punny!;)

> 
> > BTW, I not interested in arguments that the old Ada 83 code was actually
> > incorrect when it first written.  I am interested in finding out wats to
> > update it so that it works as one would expect ;) in Ada 95.
> 
> Any generic that uses "=" for a generic formal type should explicitly
> import "=" for the type:

Ugh!  So _are_ you saying that the Ada 83 code was defective wrt. Ada
83?

> 
> generic -- Some_Package
>    type T is private;
>    with function "=" (Left : T; Right : T) return Boolean is <>;
> package Some_Package is
> ...
> 
> > think of now is ethier add
> >
> >   function "=" (L,R: Private_Type) return Boolean is "=";
> 
> The construct
> 
>    is "="
> 
> on a generic formal function (note that you need "with" before
> "function") refers to a function named "=" that is visible when the
> generic is compiled. Such a function is unlikely to exist for a generic
> formal private type. To refer to a function "=" that is visible when the
> generic is instantiated, which is probably what you wanted, use
> 
>    is <>
> 
> instead.

Okay, yeah, that actually is what I had used.

> 
> > P.S. Wow its late, I hope (all/most;) of the above makes sense!

> 
> Possibly.
> 
> --
> Jeff Carter
> "I waggle my private parts at your aunties."
> Monty Python & the Holy Grail

Re: Redefined "=" = generic disaster?

[Jeff Carter]

Vincent Marciante wrote:
> Ugh!  So _are_ you saying that the Ada 83 code was defective wrt.
Ada
> 83?

In Ada 83, you could not redefine "=" for any type that could be used
to instantiate the generic, so if you wrote "=" in the generic, it meant
you wanted the predefined "=" for the type. This is still the case in
Ada if you do not explicitly import "=". If, in Ada 83, you wanted
some other behavior than the predefined "=", you still had to import it:

with function Equal (Left : T; Right : T) return Boolean;

The only real change in Ada is that now you can use the infix "=" to
represent user-defined equality, while in Ada 83 you had to use
something less intuitive. In either language, you get the predefined
"=" if you don't import something else, and have to import something
else if you don't want the predefined behavior.

-- 
Jeff Carter
"Go and boil your bottom."
Monty Python & the Holy Grail

Re: Redefined "=" = generic disaster?

[Vincent Marciante]

Jeff Carter wrote:
> 
> Vincent Marciante wrote:
> > Ugh!  So _are_ you saying that the Ada 83 code was defective wrt. Ada
> > 83?
> 
> In Ada 83, you could not redefine "=" for any type that could be used to
> instantiate the generic, so if you wrote "=" in the generic, it meant
> you wanted the predefined "=" for the type.

My point is that in Ada 83, if predefined "=" of a type did not agree
with the concept of equality that a designer intended for the type then
that designer should have eliminated it by declaring the type as
limitted private thereby not allowing it to be used to instantiate a
generic designed by someone else that imported a simple private type (I
say safely assuming that if the predefined "=" is available then it is a
semanticly correct eqality.)

(the first way that I tried to clarify my point follows - I'm still not
sure if either is clear enough, that why I didn't delete it.)

I understand this.  My point is that in Ada 83, if some one wanted to
create one ADT whose semantics required changing the condition for
equality then because it _had_ to be made limited private, the creater
of _some_another_ ADT could depend on the fact that even though a formal
equality operation was _not_ expliciely specified in _his_ ADT, using
the "=" associated with any formal private type was safe!  Or stated the
other way around, if the first guy's ADT's semantics were such that the
value returned by the predefined "=" for his type did not agree with the
semantics of the ADT that he was trying to design, then allowing "=" to
continue to exist (by not having used a limitted private type) would be
considered a defect in _his_ ADT - not a defect in an Ada 83 generic
unit that imported a mear private type (and implicitely assumably
semanticly correct equality operation of the type used to instantiate
his generic unit.) 

Do you see that I think that I am seeing a subtle issue about what could
be assumed in Ada 83 verse Ada 95.  


> This is still the case in
> Ada if you do not explicitly import "=". If, in Ada 83, you wanted some
> other behavior than the predefined "=", you still had to import it:
> 
> with function Equal (Left : T; Right : T) return Boolean;
> 
> The only real change in Ada is that now you can use the infix "=" to
> represent user-defined equality, while in Ada 83 you had to use
> something less intuitive. In either language, you get the predefined "="
> if you don't import something else, and have to import something else if
> you don't want the predefined behavior.
> 
> --
> Jeff Carter
> "I waggle my private parts at your aunties."
> Monty Python & the Holy Grail

Re: Redefined "=" = generic disaster?

[Vincent Marciante]

Jeff Carter wrote:
> 
> Vincent Marciante wrote:
> 
> > BTW, I not interested in arguments that the old Ada 83 code was actually
> > incorrect when it first written.  I am interested in finding out wats to
> > update it so that it works as one would expect ;) in Ada 95.
> 
> Any generic that uses "=" for a generic formal type should explicitly
> import "=" for the type:
> 

After a long bike ride (to get the juices flowing) I now also recognize
that because there can actually be two coexisting yet distinct concepts
of equality (equivallent and same) then explicitely importing an
equality operation would allow the desired kind of equality to be
specified when instantiating the generic.

I still think that this all opens up the possibility of more unexpected
results in Ada 95 than it did in Ada 83.

Thanks

Re: Redefined "=" = generic disaster?

[Robert Dewar]

In article <39F1F686.26B5@li.net>,
  Vincent Marciante <marciant@li.net> wrote:
> I still think that this all opens up the possibility of more
> unexpected results in Ada 95 than it did in Ada 83.

I don't see it. Of course anything can be unexpected to anyone
depending on what they know and what they expect :-)

Please post exact Ada 95 code that works (check it out first)
and does something you consider unexpected.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Redefined "=" = generic disaster?

[Vincent Marciante]

Robert Dewar wrote:
> 
> In article <39F1F686.26B5@li.net>,
>   Vincent Marciante <marciant@li.net> wrote:
> > I still think that this all opens up the possibility of more
> > unexpected results in Ada 95 than it did in Ada 83.
> 
> I don't see it. Of course anything can be unexpected to anyone
> depending on what they know and what they expect :-)
> 
> Please post exact Ada 95 code that works (check it out first)
> and does something you consider unexpected.

Okay, but no time right now - I will soon.

Re: Redefined "=" = generic disaster?

[Lao Xiao Hai]

Robert Dewar wrote:

> Please post exact Ada 95 code that works (check it out first)
> and does something you consider unexpected.

Could not resist posting this package specification and body in response

to your challenge Robert.   Before you read it, I admit it is silly to
the
point of being frivolous, but not that far removed from some code that
actually finds its way into some designs.

package Strange_Equality is

   type Strange is private;
   type Grisly  is private;
   type Goulish is private;

   function "=" (G1 : Grisly;  G2 : Goulish) return Strange;

private

  type Strange is range -1..3;
  type Grisly  is (Red, Yellow, Blue);
  type Goulish is digits 7;

end Strange_Equality;

  with the following package body

package body Strange_Equality is

   function "=" (G1 : Grisly;  G2 : Goulish) return Strange is
   begin
      if Grisly'Pos(G1) = Integer(G2) then
         return Grisly'Pos(G1);
      else
         return Strange'First;
      end if;
   end "=";

end Strange_Equality;

Re: Redefined "=" = generic disaster?

[Robert Dewar]

In article <39FCEFAD.56BE85B1@ix.netcom.com>,
  Lao Xiao Hai <laoxhai@ix.netcom.com> wrote:
> Could not resist posting this package specification and body
> in response to your challenge Robert.

OK, you posted the code. My request was to post code that did
something other than what you would expect from reading the
code. I can't see that this is true, but then I am not
telepathic, I cannot guess what peculiar expectations you
might have.

Please explain why this code does something different from
what you expect?


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Redefined "=" = generic disaster?

[Lao Xiao Hai]

Robert Dewar wrote:

> In article <39FCEFAD.56BE85B1@ix.netcom.com>,
>   Lao Xiao Hai <laoxhai@ix.netcom.com> wrote:
> > Could not resist posting this package specification and body
> > in response to your challenge Robert.
>
> OK, you posted the code. My request was to post code that did
> something other than what you would expect from reading the
> code. I can't see that this is true, but then I am not
> telepathic, I cannot guess what peculiar expectations you
> might have.
>
> Please explain why this code does something different from
> what you expect?

As I recall, the discussion had something to do with unreliable
expectations with regard to overloading the equality operator.
It is true that someone reading my example would have no
particular expectation.   It is also true that your selection of
the word "peculiar" to describe the example is appropriate.

The point of the posting is that one can certainly overload the
equality operator in strange ways and those can be coded so
as to obfuscate any reasonable meaning.    It is a short step
from there to obfuscation of the intended meaning.   Sadly,
there are those among us (mostly in the C++ world, I suppose),
who seem to delight in obfuscated code.  In other cases, someone
does it thoughtlessly.   Just today, someone showed me a package
specification in which he had overloaded the equality operator for
a generic formal record parameter.   What he intended the equality
operator to do and what one might have reasonably expected were
far from the same.  I suggested the following, to coincide with his
intentions.

Instead of,

          function "=" (L, R : Item) return Boolean;

he needed,

         function Key_Is_Equal(L, R : Item) return Boolean;

With this operation, any user knows what to expect of the contract.
That is often not the case with overloading of the "=" by itself.

Richard Riehle

Re: Redefined "=" = generic disaster?

[Vincent Marciante]

>Lao Xiao Hai wrote:
> 
> As I recall, the discussion had something to do with unreliable
> expectations with regard to overloading the equality operator.

The (wrong) expectation that I was presenting, was that of 
expecting the redefined "=" to be the "=" that would be used
in a generic that imported a private type _and_utilized_ the 
implicitely imported "=".  

The point was not that a screwy "=" could be defined for a private
type in Ada 95 - but that an Ada 83 generic could depend on the
fact that it would be getting the "=" that an instantiator expected
it to get. (If predefined "=" did not produce the approriate results
for his ADT then the designer of the type being used in the 
instantiation would have taken it away by making the type limitted
private and as a result, that type would not have been able to have
been used as the actual type in the instantiation.)  Now in Ada 95,
someone might think "hey! instead of making my ADT (whose predefined
"=" does not exhibit the desired semantics) be limitted private I can
simply override "=" and then be able to use my ADT in instances of
that old Ada 83 generic code that imports a private type.  Kewl!"

But we know that his instance will not work as he expects; yes, the
instantiation will compile but the (he thinks) overriding "=" that he
define is not used in the instance, predefined "=" is!

Re: Redefined "=" = generic disaster?

[Robert Dewar]

In article <39FE3C35.64CBB3C7@ix.netcom.com>,
  Lao Xiao Hai <laoxhai@ix.netcom.com> wrote:

>The point of the posting is that one can certainly overload the
>equality operator in strange ways and those can be coded so
>as to obfuscate any reasonable meaning.

I still don't get it, the original claim was that there was
something special about "=" that made things particularly
awkward.

Your example just shows that you can choose to overload "="
unwisely, but that is true for any operator, e.g. if you
make "+" do a subtraction, or for that matter any badly
named function. A "Put" function that actually does a read
is equally confusing.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Redefined "=" = generic disaster?

[Mats Weber]

Robert Dewar wrote:

> [...]
> I still don't get it, the original claim was that there was
> something special about "=" that made things particularly
> awkward.
> [...]

I first wanted to shut up on this issue when I saw it reemerge. But I
can't tell people to go to deja.com and search for it because searches
for postings prior to May 15, 1999, are temporarily unavailable.

I think there really is a problem with the reemergence of predefined
operations within generics, and that problem has been acknowleged by the
Ada 95 design team: draft versions of the 9X reference manual had rules
removing the reemergence problem, but later these rules were removed in
the final Ada 95 RM. IMO, this was a mistake.

Anyway here is an example program that illustrates the problem (see code
at end of message).

The programmer defines the type V_String.T. Seeing that predefined
equality will not work on that type, for obvious reasons, he redefines 
"=", thinking predefined equality is gone for good.

Then he uses his type to instantiate a generic. Inside the generic, "="
is used. But unfortunately, it is not the redefined version of "=", but
the predefined one that does not work.

Now if we change the full definition of type T by removing the comment
before "tagged", we get the expected result inside the generic. I.e. for
tagged types, the reemergence problem does not exist.

In this example, the generic is very simple for illustration purposes.
But in a real program, P could be a package implementing an associative
table for instance. In that case, the consequence is that the same key
in the table can be inserted twice, and that existing keys in a table
will not be found.

There are other situations in which predefined equality reemerges. If we
define a record type

   type R is
	record
	   C : V_String.T;
	end record;

then "=" on R will use predefined "=" on V_String.T, except if
V_String.T is tagged.

The reemergence problem on "=" did not exist in Ada 83 because you could
only redefine "=" for limited private types (there is a contorted but
still legal way that allows redefinition of "=" for a non limited type
in Ada 83, but it was clearly not intended by the language designers IMO).

I have discussed the reemergence problem in my PhD thesis, see
http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html#RTFToC97
if you want to read more about it. I don't know if the Ada 9X drafts
with the rules to eliminate it are still online somewhere.

--
with Text_IO;

use Text_IO;

procedure Reemergence_Should_Have_Been_Removed_In_Ada_95 is

   package V_String is
   
      type T is private;
      
      function "=" (Left, Right : T) return Boolean;
      
      procedure Assign (Object : out T; Value : in String);
      
   private
   
      type T is -- tagged
         record
            Length : Natural;
            Value  : String(1 .. 100);
         end record;
         
   end V_String;
   
   
   package body V_String is
   
      function "=" (Left, Right : T) return Boolean is
      begin
         return Left.Value(1 .. Left.Length) =
                Right.Value(1 .. Right.Length);
      end;
      
      procedure Assign (Object : out T; Value : in String) is
      begin
         Object.Length := Value'Length;
         Object.Value(1 .. Value'Length) := Value;
      end;
      
   end V_String;
   
   
   generic
      type T is private;
   package P is
   
      function Compare (X, Y : T) return Boolean;
      
   end P;

   package body P is
   
      function Compare (X, Y : T) return Boolean is
      begin
         return X = Y;
      end;
      
   end P;
   
   
   package PV is new P(V_String.T);

   
   X, Y : V_String.T;
   
   use V_String;
   
begin
   Assign(X, "abcd");
   Assign(Y, "abc");
   Assign(X, "abc");
   if X = Y then
      Put_Line("X = Y outside P");
   else
      Put_Line("X /= Y outside P");
   end if;
   if PV.Compare(X, Y) then
      Put_Line("X = Y inside P");
   else
      Put_Line("X /= Y inside P");
   end if;
end;

Re: Redefined "=" = generic disaster?

[Vincent Marciante]

The example exhibits the exact behavior that I had 
been trying to describe. Thanks for posting it - 
that makes one less thing that I have to worry 
about doing in my currently limitted ;) time!

Also, I remembered the previous thread and tried to 
reread it on deja before I posted my note.  That 
previous thread didn't single out reemergence of "=" 
as being especially bad though - did it?

Vinny

P.S. Big news soon..! 

Mats Weber wrote:
> 
> Robert Dewar wrote:
> 
> > [...]
> > I still don't get it, the original claim was that there was
> > something special about "=" that made things particularly
> > awkward.
> > [...]
> 
> I first wanted to shut up on this issue when I saw it reemerge. But I
> can't tell people to go to deja.com and search for it because searches
> for postings prior to May 15, 1999, are temporarily unavailable.
> 
> I think there really is a problem with the reemergence of predefined
> operations within generics, and that problem has been acknowleged by the
> Ada 95 design team: draft versions of the 9X reference manual had rules
> removing the reemergence problem, but later these rules were removed in
> the final Ada 95 RM. IMO, this was a mistake.
> 
> Anyway here is an example program that illustrates the problem (see code
> at end of message).

...

Re: Redefined "=" = generic disaster?

[Mats Weber]

Vincent Marciante wrote:

> Also, I remembered the previous thread and tried to
> reread it on deja before I posted my note.  That
> previous thread didn't single out reemergence of "="
> as being especially bad though - did it?

Yes, one of them at least did. But I think it is in the period that is
currently not searchable with deja.com.

Re: Redefined "=" = generic disaster?

[Tucker Taft]

Mats Weber wrote:
> 
> Robert Dewar wrote:
> 
> > [...]
> > I still don't get it, the original claim was that there was
> > something special about "=" that made things particularly
> > awkward.
> > [...]
> 
> I first wanted to shut up on this issue when I saw it reemerge. But I
> can't tell people to go to deja.com and search for it because searches
> for postings prior to May 15, 1999, are temporarily unavailable.
> 
> I think there really is a problem with the reemergence of predefined
> operations within generics, and that problem has been acknowleged by the
> Ada 95 design team: draft versions of the 9X reference manual had rules
> removing the reemergence problem, but later these rules were removed in
> the final Ada 95 RM. IMO, this was a mistake.

My current thinking is that we should have preserved the Ada 83 reemergence
rules for everything except record types.  Record types are the primary
way to implement private types, which is what really matters.  Furthermore,
because a record type might contain a tagged type with a user-defined "=",
the generic instantion mechanism needs to be prepared to handle user-defined
code as part of even the predefined record "=".  On the other hand, it
could be a real implementation burden to make a generic instantiation 
substitute a user-defined operator for scalar or access types.

Bob Duff and I used to say "tagged types work right" with respect to
generics.  It might be nice to generalize that to "record types work right."

As part of this generalization, it would be nice if formal derived types
would also work "right" for record types.  To minimize incompatibilities,
this would probably require that if a type were passed to a generic
formal derived untagged record type (that's a mouthful ;-), it would need
for all of its primitive operations to be mode conformant with the corresponding
operations of the specified ancestor type.  This is a pretty mild requirement,
of course.
 
> ...
-Tucker Taft
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Redefined "=" = generic disaster?

[Robert Dewar]

In article <3A01815A.75D30E9F@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> My current thinking is that we should have preserved the Ada
> 83 reemergence rules for everything except record types.

An easy way to implement this would be to have a special pragma
for tagged type

   pragma Restricted_Tag (tagged-type-name)

This pragma would restrict tagged types as follows

  No use of 'Tag attribute
  No class types
  No derivations

(is that enough to allow a compiler to implement the tagged
type with no tag? If not, add more restrictions :-)

Now you have tagged types that of course "work right" but can
be implemented without the normal overhead of tagged types.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Redefined "=" = generic disaster?

[Robert Dewar]

In article <3A01815A.75D30E9F@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> My current thinking is that we should have preserved the Ada
> 83 reemergence rules for everything except record types.

I think this would have been a VERY hard sell. To introduce
this degree of incompatibility with Ada 83 just for syntactic
convenience (after all, no one insists that you redefine
"=" for any purpose), would have been very hard to justify.
Today, far more people find the incompatibilities between
Ada 83 and Ada 95 a bar to the use of Ada 95, than people
who go around saying "Ada is a great language, and I would
use it, except for the horrible reemergence problem.

Of course one interesting approach would have been to do
equality right in the cases where it was redefined in a manner
not possible in Ada 83 ...


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Redefined "=" = generic disaster?

[Robert Dewar]

In article <3A005722.7E0BC50@mail.com>,
  matsw@mail.com wrote:
> I think there really is a problem with the reemergence of
> predefined operations within generics, and that problem has
> been acknowleged by the Ada 95 design team: draft versions of
> the 9X reference manual had rules.

Is that all we are talking about, the reemergence of predefined
operators? I would not have guessed that (partly because I sort
of assumed that anyone discussing the language design would be
aware of this issue, and it certainly has been discussed to
death!) OK, if that is the issue, then nothing more needs to
be said!


Sent via Deja.com http://www.deja.com/
Before you buy.