Re: Future Ada language revisions?

[dewarr@my-dejanews.com]

In article <EACHUS.98Oct6183832@spectre.mitre.org>,
  eachus@spectre.mitre.org (Robert I. Eachus) wrote:
> In article <Pine.BSF.4.02A.9810031123180.20730-100000@shell5.ba.best.com>
Brian Rogoff <bpr@shell5.ba.best.com> writes:
>
>   > Yes, this is nice, though I (perhaps wrongly) feel that this solution is
>   > kind of heavy in terms of performance costs, especially if I want to have
>   > side-effecting functions on objects with value semantics.
>
>   1) You can do that!  The compiler may warn you that you are being
> naughty, but you knew that.  The idiom is to use an attribute
> definition clause to overlay an internal object:

In GNAT, we prefer to use 'Unrestricted_Access for this trick, because (a) it
retains the strong typing of the pointers, without going through addresses
and (b) it points up a possible implementation dependence more clearly than
using 'Address!










>
> with Text_IO;
> procedure Cheat_Test is
>    Test_String: String := "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>    Junk: Character;
>
>    function Cheat(X: in String) return Character is
>      Temp: Character := X(X'First);
>      Overlay: String(X'Range);
>      for Overlay'Address use X'Address;
>    begin
>      Overlay(X'First) := 'Z';
>      return Temp;
>    end Cheat;
>
> begin
>
>    Text_IO.Put_Line(Test_String);
>    Junk := Cheat(Test_String);
>    Text_IO.Put_Line(Test_String);
>
> end Cheat_Test;
>
>    Using GNAT on a Sun this program produces no warnings and:
>
> spectre% cheat_test
> ABCDEFGHIJKLMNOPQRSTUVWXYZ
> ZBCDEFGHIJKLMNOPQRSTUVWXYZ
> spectre%
>
>    If you look at RM 13.3(13), we went to a great deal of effort to
> write it to leave erroneousness to the programmer.  If you know what
> you are doing, there is no problem:
>
>    "If an Address is specified, it is the programmer's responsibility
> to ensure that the address is valid; otherwise, program execution is
> erroneous."
>
>   > Eh? READERS will look at the interface to the function and see an out
mode
>   > parameter, so they'll only be surprised if they don't read the spec.
>   > "Against stupidity the gods themselves contend in vain", right?
>
>   Correct, but irrelevant.  If the style in Ada is that functional
> notation means that--in spite of the realities above--the effect of a
> function on its parameters is benign, then a function which does
> violence to its parameters will always be unexpected.
>
>   > I see "distributed cost" has become overloaded now ;-). I think if a shop
>   > had a rule of "no access mode" or no "_Type" in type names or whatever
>   > there is also a similar cost, but I don't think that means that should be
>   > language rules enforcing restrictions here.
>
>   No, in Ada design it has always been used to mean a "feature" which
> makes things more difficult even if it is not used.  If you use the
> above approach, there is no distributed cost--you take the
> responsibility for what happens if the argument is a constant, and any
> compiler optimizer will know that an address clause is bad juju--the
> hardware may even play with the value.
>
> --
>
> 					Robert I. Eachus
>
> with Standard_Disclaimer;
> use  Standard_Disclaimer;
> function Message (Text: in Clever_Ideas) return Better_Ideas is...
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own