* Reemergence of predefined equality operator... @ 2002-07-31 22:25 Dale Stanbrough 2002-07-31 22:47 ` Robert A Duff 0 siblings, 1 reply; 8+ messages in thread From: Dale Stanbrough @ 2002-07-31 22:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Reemergence of predefined equality operator... 2002-07-31 22:25 Reemergence of predefined equality operator Dale Stanbrough @ 2002-07-31 22:47 ` Robert A Duff 2002-08-01 1:30 ` Vincent Marciante 2002-08-01 11:14 ` Dale Stanbrough 0 siblings, 2 replies; 8+ messages in thread From: Robert A Duff @ 2002-07-31 22:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Reemergence of predefined equality operator... 2002-07-31 22:47 ` Robert A Duff @ 2002-08-01 1:30 ` Vincent Marciante 2002-08-01 12:06 ` Robert Dewar 2002-08-01 11:14 ` Dale Stanbrough 1 sibling, 1 reply; 8+ messages in thread From: Vincent Marciante @ 2002-08-01 1:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Reemergence of predefined equality operator... 2002-08-01 1:30 ` Vincent Marciante @ 2002-08-01 12:06 ` Robert Dewar 2002-08-25 17:46 ` Vincent Marciante 0 siblings, 1 reply; 8+ messages in thread From: Robert Dewar @ 2002-08-01 12:06 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Reemergence of predefined equality operator... 2002-08-01 12:06 ` Robert Dewar @ 2002-08-25 17:46 ` Vincent Marciante 2002-08-25 22:04 ` Robert A Duff 0 siblings, 1 reply; 8+ messages in thread From: Vincent Marciante @ 2002-08-25 17:46 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Reemergence of predefined equality operator... 2002-08-25 17:46 ` Vincent Marciante @ 2002-08-25 22:04 ` Robert A Duff 0 siblings, 0 replies; 8+ messages in thread From: Robert A Duff @ 2002-08-25 22:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Reemergence of predefined equality operator... 2002-07-31 22:47 ` Robert A Duff 2002-08-01 1:30 ` Vincent Marciante @ 2002-08-01 11:14 ` Dale Stanbrough 2002-08-01 14:48 ` Robert A Duff 1 sibling, 1 reply; 8+ messages in thread From: Dale Stanbrough @ 2002-08-01 11:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Reemergence of predefined equality operator... 2002-08-01 11:14 ` Dale Stanbrough @ 2002-08-01 14:48 ` Robert A Duff 0 siblings, 0 replies; 8+ messages in thread From: Robert A Duff @ 2002-08-01 14:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-08-25 22:04 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-07-31 22:25 Reemergence of predefined equality operator Dale Stanbrough 2002-07-31 22:47 ` Robert A Duff 2002-08-01 1:30 ` Vincent Marciante 2002-08-01 12:06 ` Robert Dewar 2002-08-25 17:46 ` Vincent Marciante 2002-08-25 22:04 ` Robert A Duff 2002-08-01 11:14 ` Dale Stanbrough 2002-08-01 14:48 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox