Is this a bug?

Is this a bug?

[reinert]

Hello,

assume the following Ada procedure:
------------------------------------------------------------------------------
with Text_IO;
procedure test1 is
package test_package is
 type rec1_t is tagged record
   a : integer := 2;  
-- b : integer := 2;
 end record;
 function a(x : rec1_t) return integer is (3);
 rec1 : rec1_t;
end test_package;
begin
  Text_IO.Put(" test_package.rec1: " & integer'image(test_package.rec1.a));
end test1;
-------------------------------------------------------------------------------

It gives (for mye computer): 

test_package.rec1:  2

If I change the statement 

"a : integer := 2;"

to

"b : integer := 2;"

then I get:

test_package.rec1:  3

Is this reasonable?  Bug?

reinert

Re: Is this a bug?

[Anh Vo]

On Monday, December 30, 2019 at 7:44:37 AM UTC-8, reinert wrote:
> Hello,
> 
> assume the following Ada procedure:
> ------------------------------------------------------------------------------
> with Text_IO;
> procedure test1 is
> package test_package is
>  type rec1_t is tagged record
>    a : integer := 2;  
> -- b : integer := 2;
>  end record;
>  function a(x : rec1_t) return integer is (3);
>  rec1 : rec1_t;
> end test_package;
> begin
>   Text_IO.Put(" test_package.rec1: " & integer'image(test_package.rec1.a));
> end test1;
> -------------------------------------------------------------------------------
> 
> It gives (for mye computer): 
> 
> test_package.rec1:  2
> 
> If I change the statement 
> 
> "a : integer := 2;"
> 
> to
> 
> "b : integer := 2;"
> 
> then I get:
> 
> test_package.rec1:  3
> 
> Is this reasonable?  Bug?
> 
> reinert

No, the compiler behaves correctly. In fact, if tagged record is replaced by record, the latter case will be rejected.

Anh Vo

Re: Is this a bug?

[Niklas Holsti]

On 2019-12-30 19:51, Anh Vo wrote:
> On Monday, December 30, 2019 at 7:44:37 AM UTC-8, reinert wrote:
>> Hello,
>>
>> assume the following Ada procedure:
>> ------------------------------------------------------------------------------
>> with Text_IO;
>> procedure test1 is
>> package test_package is
>>   type rec1_t is tagged record
>>     a : integer := 2;
>> -- b : integer := 2;
>>   end record;
>>   function a(x : rec1_t) return integer is (3);
>>   rec1 : rec1_t;
>> end test_package;
>> begin
>>    Text_IO.Put(" test_package.rec1: " & integer'image(test_package.rec1.a));
>> end test1;
>> -------------------------------------------------------------------------------
>>
>> It gives (for mye computer):
>>
>> test_package.rec1:  2
>>
>> If I change the statement
>>
>> "a : integer := 2;"
>>
>> to
>>
>> "b : integer := 2;"
>>
>> then I get:
>>
>> test_package.rec1:  3
>>
>> Is this reasonable?  Bug?
>>
>> reinert
> 
> No, the compiler behaves correctly. In fact, if tagged record is
> replaced by record, the latter case will be rejected.

Yes.

When rec1_t is tagged, the "selected component" text 
"test_package.rec1.a" could refer either to the rec1_t-component "a" or 
to the subprogram (function) "a". In RM 4.1.3(9.1/2) and RM 
4.1.3(9.2/3), the latter case is available only under the condition that 
the tagged record type (rec1_t) does not have a (visible) component with 
the name "a". This means that the ambiguity is resolved in favour of the 
component "a", which has the value 2.

One could ask, why is such an ambiguity not rejected (made illegal)? 
Probably because such an illegality rule would have made many illegal 
many Ada programs that were legal before the introduction of the 
"object.operation" syntax for tagged-record objects.

If this is a problem for you, you might check if your compiler has an 
option to warn about such cases, or if AdaControl can do the same.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Is this a bug?

[reinert]

mandag 30. desember 2019 19.41.10 UTC+1 skrev Niklas Holsti følgende:

> 
....
> One could ask, why is such an ambiguity not rejected (made illegal)? 
> Probably because such an illegality rule would have made many illegal 
> many Ada programs that were legal before the introduction of the 
> "object.operation" syntax for tagged-record objects.
> 

I have had the understanding that the *intention* of primitive operations of tagged (record) types in some way can be looked at as an extension of the actual record - especially if one uses the dot notation.  In this case I would expect (at least) a warning from the compiler.

I discovered the ambiguity when I accidentally did put in an extra component in a tagged record and with the same name as a primitive function of it (introduced long ago). Then the (old) primitive function suddenly seemed to give strange results :-) So after this experience I will be careful about possible name collisions between record components and primitive functions.

reinert
https://korsnesbiocomputing.no/

Re: Is this a bug?

[Dmitry A. Kazakov]

On 2019-12-30 20:50, reinert wrote:

> I have had the understanding that the *intention* of primitive operations of tagged (record) types in some way can be looked at as an extension of the actual record - especially if one uses the dot notation.  In this case I would expect (at least) a warning from the compiler.

Actually a correct design would be equivalence of a record member with 
two primitive operations getter and setter AKA abstract record 
interface. In that case the program would become incorrect.

All this is also related to the problem of private primitive operations.

A lot of legacy code will get broken if attempted to fix these.

IMO it would be better to design a new abstract type system from scratch 
and implement tagged types with all their quirks on top of it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this a bug?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:h6uum4F2481U1@mid.individual.net...
> On 2019-12-30 19:51, Anh Vo wrote:
>> On Monday, December 30, 2019 at 7:44:37 AM UTC-8, reinert wrote:
>>> Hello,
>>>
>>> assume the following Ada procedure:
>>> ------------------------------------------------------------------------------
>>> with Text_IO;
>>> procedure test1 is
>>> package test_package is
>>>   type rec1_t is tagged record
>>>     a : integer := 2;
>>> -- b : integer := 2;
>>>   end record;
>>>   function a(x : rec1_t) return integer is (3);
>>>   rec1 : rec1_t;
>>> end test_package;
>>> begin
>>>    Text_IO.Put(" test_package.rec1: " & 
>>> integer'image(test_package.rec1.a));
>>> end test1;
>>> -------------------------------------------------------------------------------
>>>
>>> It gives (for mye computer):
>>>
>>> test_package.rec1:  2
>>>
>>> If I change the statement
>>>
>>> "a : integer := 2;"
>>>
>>> to
>>>
>>> "b : integer := 2;"
>>>
>>> then I get:
>>>
>>> test_package.rec1:  3
>>>
>>> Is this reasonable?  Bug?
>>>
>>> reinert
>>
>> No, the compiler behaves correctly. In fact, if tagged record is
>> replaced by record, the latter case will be rejected.
>
> Yes.
>
> When rec1_t is tagged, the "selected component" text "test_package.rec1.a" 
> could refer either to the rec1_t-component "a" or to the subprogram 
> (function) "a". In RM 4.1.3(9.1/2) and RM 4.1.3(9.2/3), the latter case is 
> available only under the condition that the tagged record type (rec1_t) 
> does not have a (visible) component with the name "a". This means that the 
> ambiguity is resolved in favour of the component "a", which has the value 
> 2.
>
> One could ask, why is such an ambiguity not rejected (made illegal)? 
> Probably because such an illegality rule would have made many illegal many 
> Ada programs that were legal before the introduction of the 
> "object.operation" syntax for tagged-record objects.

The other reason is that there isn't any alternative notation available for 
components, whereas there is an alternative method for function calls. Ergo, 
we assume that you mean a component if both are available -- otherwise, it 
would be impossible to access a component at all if there is a function with 
the same name visible. Since that function wouldn't even have to be in the 
same scope, there would be a significant maintainance hazard.

Moral: This is another reason to make everything a private type (and also to 
not use prefixed notation with types that aren't private).

                                      Randy.

Re: Is this a bug?

[J-P. Rosen]

Le 30/12/2019 à 19:41, Niklas Holsti a écrit :
> If this is a problem for you, you might check if your compiler has an
> option to warn about such cases, or if AdaControl can do the same.
Not yet, but it's a good idea. I keep it as an improvement suggestion.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Is this a bug?

[Optikos]

On Monday, December 30, 2019 at 5:16:19 PM UTC-6, Randy Brukardt wrote:
> "Niklas Holsti" wrote in message 
> news:h6uum4F2481U1@mid.individual.net...
> > On 2019-12-30 19:51, Anh Vo wrote:
> >> On Monday, December 30, 2019 at 7:44:37 AM UTC-8, reinert wrote:
> >>> Hello,
> >>>
> >>> assume the following Ada procedure:
> >>> ------------------------------------------------------------------------------
> >>> with Text_IO;
> >>> procedure test1 is
> >>> package test_package is
> >>>   type rec1_t is tagged record
> >>>     a : integer := 2;
> >>> -- b : integer := 2;
> >>>   end record;
> >>>   function a(x : rec1_t) return integer is (3);
> >>>   rec1 : rec1_t;
> >>> end test_package;
> >>> begin
> >>>    Text_IO.Put(" test_package.rec1: " & 
> >>> integer'image(test_package.rec1.a));
> >>> end test1;
> >>> -------------------------------------------------------------------------------
> >>>
> >>> It gives (for mye computer):
> >>>
> >>> test_package.rec1:  2
> >>>
> >>> If I change the statement
> >>>
> >>> "a : integer := 2;"
> >>>
> >>> to
> >>>
> >>> "b : integer := 2;"
> >>>
> >>> then I get:
> >>>
> >>> test_package.rec1:  3
> >>>
> >>> Is this reasonable?  Bug?
> >>>
> >>> reinert
> >>
> >> No, the compiler behaves correctly. In fact, if tagged record is
> >> replaced by record, the latter case will be rejected.
> >
> > Yes.
> >
> > When rec1_t is tagged, the "selected component" text "test_package.rec1.a" 
> > could refer either to the rec1_t-component "a" or to the subprogram 
> > (function) "a". In RM 4.1.3(9.1/2) and RM 4.1.3(9.2/3), the latter case is 
> > available only under the condition that the tagged record type (rec1_t) 
> > does not have a (visible) component with the name "a". This means that the 
> > ambiguity is resolved in favour of the component "a", which has the value 
> > 2.
> >
> > One could ask, why is such an ambiguity not rejected (made illegal)? 
> > Probably because such an illegality rule would have made many illegal many 
> > Ada programs that were legal before the introduction of the 
> > "object.operation" syntax for tagged-record objects.
> 
> The other reason is that there isn't any alternative notation available for 
> components, whereas there is an alternative method for function calls. Ergo, 
> we assume that you mean a component if both are available -- otherwise, it 
> would be impossible to access a component at all if there is a function with 
> the same name visible. Since that function wouldn't even have to be in the 
> same scope, there would be a significant maintainance hazard.
> 
> Moral: This is another reason to make everything a private type (and also to 
> not use prefixed notation with types that aren't private).

Another moral to the story:
This is a reason for language designers to not import some other language's syntax in •verbatim• (in Ada95) just because all the cool OO kids were doing member-dot syntax (during the late-1980s & 1990s).  Perhaps a quite-visual multi-character token would have been better (e.g., dot-colon .: as a metaphor for zoom-in magnification or colon-dot :. for drill-down to a part within the whole).  Or perhaps tilde (~) or commercial-at (@) or back-tick (`) would have been better, if a single-character token was the only option.

Re: Is this a bug?

[Randy Brukardt]

"Optikos" <optikos@verizon.net> wrote in message 
news:d770cfc3-0d99-4b4f-af61-22e9ec849ba7@googlegroups.com...
...
>Another moral to the story:
>This is a reason for language designers to not import some other language's 
>syntax
>in .verbatim. (in Ada95) just because all the cool OO kids were doing 
>member-dot
>syntax (during the late-1980s & 1990s).  Perhaps a quite-visual 
>multi-character
>token would have been better (e.g., dot-colon .: as a metaphor for zoom-in
>magnification or colon-dot :. for drill-down to a part within the whole). 
>Or perhaps
>tilde (~) or commercial-at (@) or back-tick (`) would have been better, if 
>a
>single-character token was the only option.

We thought about that, but Ada has always had prefix calls for task entries 
(all the way back to Ada 83) and for protected operations in Ada 95. 
Extending and normalizing that notion for tagged objects made more sense 
than inventing yet another similar notation.

In addition, the model of Ada has been that array indexing and function 
calls are syntactically interchangeable. It makes sense to use a similar 
model for components/subprogram calls.

The best possible fix here would be to find some alternative notation for 
record components so that there would be a work-around in case the primary 
notation doesn't work. That's the overall scheme for Ada: there is always a 
(lengthy) way to write something when a shorter form becomes impossible 
because of a conflict. The lack of such an "escape hatch" for record 
components leads to adopting a suboptimal rule.

That probably has to wait for a reimagined Ada, however, since it wouldn't 
be compatible. There's plenty of things that Ada got wrong at some point or 
other that we can't change because of compatibility concerns (overloading of 
objects is probably at the top of that list for me). Whether those 
improvements would be enough to encourage moving to a different, somewhat 
incompatible Ada is unclear.

                        Randy.

Re: Is this a bug?

[Dmitry A. Kazakov]

On 2019-12-31 22:50, Randy Brukardt wrote:

> The best possible fix here would be to find some alternative notation for
> record components so that there would be a work-around in case the primary
> notation doesn't work.

    A'Component (B)

    B of A

etc for A.B.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this a bug?

[reinert]

torsdag 2. januar 2020 10.34.17 UTC+1 skrev Dmitry A. Kazakov følgende:
> On 2019-12-31 22:50, Randy Brukardt wrote:
> 
> > The best possible fix here would be to find some alternative notation for
> > record components so that there would be a work-around in case the primary
> > notation doesn't work.
> 
>     A'Component (B)
> 
>     B of A
> 
> etc for A.B.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

But I kind of like the concept of "extending" the record as illustrated here:

type rec1_t is tagged record
   a : Integer := 2;
   b : integer := 2;
end record;
function c(x: rec1_t) return Integer is (x.a + x.b);
rec1 : rec1_t;

And then rec1.c = 4 is true.

reinert

Re: Is this a bug?

[reinert]

torsdag 2. januar 2020 10.34.17 UTC+1 skrev Dmitry A. Kazakov følgende:
> On 2019-12-31 22:50, Randy Brukardt wrote:
> 
> > The best possible fix here would be to find some alternative notation for
> > record components so that there would be a work-around in case the primary
> > notation doesn't work.
> 
>     A'Component (B)
> 
>     B of A
> 
> etc for A.B.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

But I kind of like the concept of "extending" the record as illustrated here:

type rec1_t is tagged record
   a : Integer := 2;
   b : integer := 2;
end record;
function c(x: rec1_t) return Integer is (x.a + x.b);
rec1 : rec1_t;

And then rec1.c = 4 is true.

But what is really the problem of prohibiting to include above:

function a(x: rec1_t) return Integer is (5);  

?

This is similar to that the following is not legal:

type rec1_t is tagged record
   a : Integer := 2;
   b : Integer := 2;
   a : Integer := 5; -- is not legal.
end record;

?

reinert

Re: Is this a bug?

[Dmitry A. Kazakov]

On 2020-01-03 08:35, reinert wrote:
> torsdag 2. januar 2020 10.34.17 UTC+1 skrev Dmitry A. Kazakov følgende:
>> On 2019-12-31 22:50, Randy Brukardt wrote:
>>
>>> The best possible fix here would be to find some alternative notation for
>>> record components so that there would be a work-around in case the primary
>>> notation doesn't work.
>>
>>      A'Component (B)
>>
>>      B of A
>>
>> etc for A.B.
>>
>> -- 
>> Regards,
>> Dmitry A. Kazakov
>> http://www.dmitry-kazakov.de
> 
> But I kind of like the concept of "extending" the record as illustrated here:
> 
> type rec1_t is tagged record
>     a : Integer := 2;
>     b : integer := 2;
> end record;
> function c(x: rec1_t) return Integer is (x.a + x.b);
> rec1 : rec1_t;
> 
> And then rec1.c = 4 is true.
> 
> But what is really the problem of prohibiting to include above:
> 
> function a(x: rec1_t) return Integer is (5);
> 
> ?
> 
> This is similar to that the following is not legal:
> 
> type rec1_t is tagged record
>     a : Integer := 2;
>     b : Integer := 2;
>     a : Integer := 5; -- is not legal.
> end record;
> 
> ?

Yes, but that is was not possible, because in Ada 95 the function "a" 
did not conflict with members. The change in Ada 2005 introduced dot 
notation and thus the conflict.

What Randy meant is a different issue that there is no "fully qualified" 
form to get a record member since Ada 2005 change made "." overloaded.

If "." were a first-class operation, then one would have it:

    "." (X, "a")   vs   a (X)

Such operation could be very difficult to introduce.

    X'Component (A)

or

    A of X

are much simpler.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this a bug?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:qumug8$1bsj$1@gioia.aioe.org...
> On 2020-01-03 08:35, reinert wrote:
...
>> But what is really the problem of prohibiting to include above:
>>
>> function a(x: rec1_t) return Integer is (5);
>>
>> ?
>>
>> This is similar to that the following is not legal:
>>
>> type rec1_t is tagged record
>>     a : Integer := 2;
>>     b : Integer := 2;
>>     a : Integer := 5; -- is not legal.
>> end record;
>>
>> ?
>
> Yes, but that is was not possible, because in Ada 95 the function "a" did 
> not conflict with members. The change in Ada 2005 introduced dot notation 
> and thus the conflict.

It also doesn't really fix the problem unless one starts breaking privacy. 
It's not just direct local declarations that cause problems, but also 
inherited routines and class-wide routines associated with ancestors. And 
since components can become visible at later points, you can also have 
something that is legal in a specification be illegal in a body (especially 
possible for child units).

For instance, if you have something like:

    package P is
       type Root is tagged private;
       function C1 (A : Root) return Boolean;
       function C2 (B : Root'Class) return Boolean;
   private
       type Root is tagged record
            C3 : Natural;
       end record;
   end P;

Then, for

    Obj : Root;

Obj.C1 and Obj.C2 are legal.

    package P.Child is
          type New_Type is new Root with record
                 ??? : Natural;
          end record;
          function C3 (A : New_Type) return Boolean; -- Nope.
    end P.Child;

New_Type cannot have components named C1 or C2, so if ??? has either of 
those names, it has to be illegal. In addition, the function has to be 
banned because the component C3 will be visible in the body of P.Child. (??? 
is illegal if it is C3.)

Because of the cases illustrated above, you also now have much more 
significant maintenance problem. Imagine that P is some package out of your 
control, like a GTKAda or even an Ada.Container package.

As Ada stands, one can add a subprogram to a package without having too 
worry much about incompatibility. Conflicts are possible, but only matter if 
the entire profile of the new subprogram matches. In cases like this, *any* 
matching causes problems. That's because objects aren't overloadable in Ada, 
so a component conflicts with any subprogram with the same name and prefix 
parameter.

One can imagine making objects overloadable in Ada to avoid this problem 
(the language would probably have been better if that had been the case), 
but that can lead to the worst possible incompatibility: a program that 
compiles and means something different than it does in current Ada. To avoid 
that, you have to have some additional complex rules. And, of course if this 
was done, we don't need the original rule at all (just let true conflicts 
happen). So we're pretty much back where we started from.

In a language designed from the ground up to have this sort of prefix 
notation for functions, there'd be no problem. But Ada isn't that language.

                                   Randy.

Re: Is this a bug?

[reinert]

So a preliminary conclusion here for a regular ada programmer may be to practice using tools such as adacontrol (adactl)?  I see it is available under debian.

I have just started to try it out using gnatcheck.aru as rule file :-)

reinert

Re: Is this a bug?

[J-P. Rosen]

Le 05/01/2020 à 14:32, reinert a écrit :
> I have just started to try it out using gnatcheck.aru as rule file :-)

This is not the best option to start from, as it provides only the
AdaControl equivalent of Gnatcheck rules - so you won't benefit from the
many extra possibilities of AdaControl ;-). This file is intended to
ease migration from Gnatcheck to AdaControl .

A good starting point is verif.aru (common rules) or nasa.aru (nasa
coding guidelines) in directory "rules".

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Is this a bug?

[Tero Koskinen]

Hi,

J-P. Rosen wrote on 6.1.2020 12.43:
> Le 05/01/2020 à 14:32, reinert a écrit :
>> I have just started to try it out using gnatcheck.aru as rule file :-)
> 
> This is not the best option to start from, as it provides only the
> AdaControl equivalent of Gnatcheck rules - so you won't benefit from the
> many extra possibilities of AdaControl ;-). This file is intended to
> ease migration from Gnatcheck to AdaControl .
> 
> A good starting point is verif.aru (common rules) or nasa.aru (nasa
> coding guidelines) in directory "rules".

My Ahven library also has a set of AdaControl rules:

https://hg.sr.ht/~tkoskine/ahven/browse/default/rules/ahven.aru

Yours,
  Tero

Re: Is this a bug?

[reinert]

fredag 3. januar 2020 09.37.32 UTC+1 skrev Dmitry A. Kazakov følgende:
.....
> 
> Yes, but that is was not possible, because in Ada 95 the function "a" 
> did not conflict with members. The change in Ada 2005 introduced dot 
> notation and thus the conflict.
> 

Still I struggle to understand this. Why could it not be possible to tell the compiler that "this is Ada strict and do not - for god's sake - accept such possible ambiguities" ?

reinert

Re: Is this a bug?

[Dmitry A. Kazakov]

On 2020-01-17 10:54, reinert wrote:
> fredag 3. januar 2020 09.37.32 UTC+1 skrev Dmitry A. Kazakov følgende:
> .....
>>
>> Yes, but that is was not possible, because in Ada 95 the function "a"
>> did not conflict with members. The change in Ada 2005 introduced dot
>> notation and thus the conflict.
> 
> Still I struggle to understand this. Why could it not be possible to tell the compiler that "this is Ada strict and do not - for god's sake - accept such possible ambiguities" ?

If you borrow stuff from other, let me say it, inferior languages, you 
borrow problems of these languages with. Not everyone was happy with Ada 
2005, 2012, with the ideas behind the changes, with the ways these ideas 
were implemented. I was not.

Regardless what I said, the dot notation is quite useful (and natural to 
Ada, see Ada 83 tasks). One just should have been more careful the way 
it was introduced. If it would apply to all types, not just tagged 
records, then potential problems would be more visible and hopefully 
resolved at the time. Many recent Ada changes suffer "tunnel vision" effect.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this a bug?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]


"reinert" <reinkor@gmail.com> wrote in message 
news:c02eb3b5-68e7-431e-bc3c-74dc278409ed@googlegroups.com...
fredag 3. januar 2020 09.37.32 UTC+1 skrev Dmitry A. Kazakov følgende:
.....
>>
>> Yes, but that is was not possible, because in Ada 95 the function "a"
>> did not conflict with members. The change in Ada 2005 introduced dot
>> notation and thus the conflict.

>Still I struggle to understand this. Why could it not be possible to tell 
>the compiler
>that "this is Ada strict and do not - for god's sake - accept such possible 
>ambiguities" ?

Possible, I suppose, but Ada (to date) does not have error "modes" -- either 
something is an error or it is not. If something is enough of a problem to 
reject it, there almost never a sensible

And, as previously noted, if A.Component is ambiguous, there is no notation 
for accessing the component in some other way. So such a component is 
completely inaccessible - the only choice is to rename it. That's a problem 
waiting to happen, especially for those working on top of OOP hierarchies 
where they don't own the root type. If someone adds a conflicting operation, 
now you're forced to change the component names of all of your code.

And this sort of conflict is not that unusual in private types. I have a 
number of private types where I have a component (in the private part) and a 
getter function (that's visible) with the same name. There's no conflict 
with users outside of the package, but an ambiguity would require changing 
the name of the component. (And such a change itself could be dangerous, as 
any uses that got missed would silently change to calling the Getter 
function - a possible problem of infinite recursion or (if the getter does 
more than just return the value) doing extra uninitended operations.

I think an ambiguity rule in a new language with thought-out alternatives 
probably would be preferable, but it wouldn't work well in Ada.

                                                       Randy.

Re: Is this a bug?

[Warren W. Gay VE3WWG]

Stephen Leake wrote:

> "Jeff C r e e.m" <jcreem@yahoo.com> writes:
>>"Stephen Leake" <stephen_leake@acm.org> wrote in message >
>>
>>>Hmm. GCC does not _always_ include Ada; the only language in the root
>>>gcc distribution is C; all other languages are in a separate
>>>distribution. So "GNAT 3.4.2" to me means "GCC 3.4.2 with Ada
>>>support". Seems like a reasonable abbreviation.
>>
>>The problem is it seems reasonable but will eventually lead to version 
>>number collision.
>>GCC 4.0 will be realeased fairly soon (Well somewhat soon).
>>
>>GNAT 4.0  was released in 1997.  GNAT 4.0 was a fully certified 
>>implementation.  Ada support in GCC 4.0 is likely to be pretty buggy.
> 
> All true. But by the time gcc 4.0 is released, it will be clear from
> context which is meant.

The problem is that Google has a long memory. Seaching historical
information becomes a greater problem if you mix the references
to products. Even in the present, you'd want to start excluding
references to dates prior to a given point in time, which is
a pain. IMHO, it is best to avoid any confusion. The Ada community
has enough challenges facing it.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Is this a bug?

[Stephen Leake]

"Jeff C r e e.m" <jcreem@yahoo.com> writes:

> "Stephen Leake" <stephen_leake@acm.org> wrote in message >
> > Hmm. GCC does not _always_ include Ada; the only language in the root
> > gcc distribution is C; all other languages are in a separate
> > distribution. So "GNAT 3.4.2" to me means "GCC 3.4.2 with Ada
> > support". Seems like a reasonable abbreviation.
> >
> 
> The problem is it seems reasonable but will eventually lead to version 
> number collision.
> GCC 4.0 will be realeased fairly soon (Well somewhat soon).
> 
> GNAT 4.0  was released in 1997.  GNAT 4.0 was a fully certified 
> implementation.  Ada support in GCC 4.0 is likely to be pretty buggy.

All true. But by the time gcc 4.0 is released, it will be clear from
context which is meant.

> I think one can reasonably say (on comp.lang.ada)
> 
> "I compiled the following with gcc 3.4.2"
> 
> And if the sample code is Ada and the error is not "No Ada compiler 
> installed on this system" then we pretty much assume that GNAT stuff is "in 
> there".

That's a good point.

> In any case it is not all that important....But with all the time we
> spend on the ADA v.s. Ada thing it seemed worth a mention ;)

Yep.

I used to insist on using the GNAT public release version numbers in
this forum. But since Ada Core has effectively stopped doing public
releases except via gcc, it seems reasonable to give up on that.

It's always appropriate to say "did you actually mean gcc 3.4.2 with
Ada" if it's not clear from context.

-- 
-- Stephe

Re: Is this a bug?

[Brian May]

>>>>> "Wojtek" == Wojtek Narczynski <wojtek@power.com.pl> writes:

    >> declare
    >> function Current is return Current_Hook.all; end Current;
    >> begin

    Wojtek> I don't think this is applicable to my code.

I think the issue here is that the value returned by the function is
read-only, and could make your code harder to read, not easier to
read.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Is this a bug?

[Wojtek Narczynski]

Hello,

> If you want a short name for a complex expression, that is re-evaluated
> each time the name is used, you need a function, not a rename:
> 
> declare
>     function Current is return Current_Hook.all; end Current;
> begin
> 
> Only 3 more identifiers!
> 

I don't think this is applicable to my code.

Regards,
Wojtek

Re: Is this a bug?

[Wojtek Narczynski]

Hello,

> If so, then "renames" isn't quite as simple as I thought. It is more
> like a "hard link" then a "symbolic link". i.e. it links to the object
> rather then the name of the object. Interesting.

Ada rename is not like C #define. Big thanks to the makers of Ada for this.

It is more apparent what's going on in my code if you move the elaboration
time initialization of Current_Hook to execution time:

is
   Current_Hook : Bucket_Access_Access;
   --  Current : Bucket_Access renames Current_Hook.all;
   --  XXX Uncommented and used causes null pointer dereference
begin
   Current_Hook  := Queue.Anchor'Unchecked_Access;

This yields immediate failure.

Another example is:

procedure Test_Rename is
   Arr : array (1..3) of Integer := (1,2);
   Ind : Positive := Arr'First;
   Curr : Integer renames Arr (Ind);
begin
   Put_Line (Curr);
   Ind := Arr'Last;
   Put_Line (Curr);
end;

This will print 1 twice.

Those #defines are one of the main reasons why C code so hard
to read and debug, so I prefer to do some more typing.

Regards,
Wojtek

  

Re: Is this a bug?

[Jeff C r e e.m]

"Stephen Leake" <stephen_leake@acm.org> wrote in message >
> Hmm. GCC does not _always_ include Ada; the only language in the root
> gcc distribution is C; all other languages are in a separate
> distribution. So "GNAT 3.4.2" to me means "GCC 3.4.2 with Ada
> support". Seems like a reasonable abbreviation.
>

The problem is it seems reasonable but will eventually lead to version 
number collision.
GCC 4.0 will be realeased fairly soon (Well somewhat soon).

GNAT 4.0  was released in 1997.  GNAT 4.0 was a fully certified 
implementation.  Ada support in GCC 4.0 is likely to be pretty buggy.

I think one can reasonably say (on comp.lang.ada)

"I compiled the following with gcc 3.4.2"

And if the sample code is Ada and the error is not "No Ada compiler 
installed on this system" then we pretty much assume that GNAT stuff is "in 
there".

In any case it is not all that important....But with all the time we spend 
on the ADA v.s. Ada thing it seemed worth a mention ;) 

Re: Is this a bug?

[Jeffrey Carter]

Stephen Leake wrote:

> Brian May <bam@snoopy.apana.org.au> writes:
> 
>>So another words, if I did the following:
>>
>>declare
>>   ...
>>   Current : Bucket_Access renames Current_Hook.all;
>>
>>begin
>>   ...
>>   Current_Hook := <something else>
>>   ...
>>end;
>>
>>Then Current would still be the same object and value it use to be?
> 
> Yes, you have it right.

This is because Current is not a renaming of Current_Hook, which is what 
gets the new value. In the common case, in which the renamed object gets 
a new value, then the renaming also reflects the change. In the example 
above, if the assignment were to Current_Hook.all, then Current would 
also change. See ARM 8.5.1.

-- 
Jeff Carter
"C++: The power, elegance and simplicity of a hand grenade."
Ole-Hjalmar Kristensen
90

Re: Is this a bug?

[Stephen Leake]

"Jeff C r e e.m" <jcreem@yahoo.com> writes:

> "Wojtek Narczynski" <wojtek@power.com.pl> wrote in message 
> news:5ad0dd8a.0409221652.6a69b336@posting.google.com...
> >
> > GNAT 3.4.2 linux. 
> > <snip>
> 
> Note I think you mean GCC 3.4.2
> 
> GNAT version numbers are disjoint from GCC version numbers and generally 
> imply a release (public or otherwise) that originated from Ada Core 
> Technologies.
> 
> (e.g. GNAT 3.15p, GNAT 5.01a).
> 
> The 3.4.2 designation is for GCC (which does not mean GNU C Compiler, it is 
> the GNU Compiler Collection). GCC 3.4.2 natively contains Ada support.

Hmm. GCC does not _always_ include Ada; the only language in the root
gcc distribution is C; all other languages are in a separate
distribution. So "GNAT 3.4.2" to me means "GCC 3.4.2 with Ada
support". Seems like a reasonable abbreviation.

-- 
-- Stephe

Re: Is this a bug?

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

> So another words, if I did the following:
> 
> declare
>    ...
>    Current : Bucket_Access renames Current_Hook.all;
> 
> begin
>    ...
>    Current_Hook := <something else>
>    ...
> end;
> 
> 
> Then Current would still be the same object and value it use to be?

Yes, you have it right.

> If so, then "renames" isn't quite as simple as I thought. 

You are not alone; it seems to be a common misunderstanding for people
learning Ada.

> It is more like a "hard link" then a "symbolic link". i.e. it links
> to the object rather then the name of the object. Interesting.

The purpose of "renames" is to cache the results of computing a
complex name. Although sometimes we think of it as just "cleaning up
the code", it can produce significant time and code space
optimization.

If you want a short name for a complex expression, that is re-evaluated
each time the name is used, you need a function, not a rename:

declare
    function Current is return Current_Hook.all; end Current;
begin

Only 3 more identifiers!

> Question: If you freed the value (with unchecked_deallocate) of
> "Current_Hook" would the value of "Current" still be valid? I
> suspect it would not be valid, as "Current" is now dangling. 

Current would be invalid.

-- 
-- Stephe

Re: Is this a bug?

[Brian May]

>>>>> "Nick" == Nick Roberts <nick.roberts@acm.org> writes:

    Nick> Wojtek Narczynski wrote:
    >> Okay, I wasn't thinking. It obviously isn't a compiler bug.

    Nick> To clarify (hopefully), there is a line which changes the
    Nick> value of Current_Hook:

    Nick>     Current_Hook := Current_Hook.all.Down'Unchecked_Access;

    Nick> The value of Current would not have been changed by this
    Nick> statement, so it would presumably have been left referring
    Nick> to the wrong thing. The code shown is quite complex, and
    Nick> Wojtek can be forgiven for initially missing this (in my
    Nick> humble opinion).

So another words, if I did the following:

declare
   ...
   Current : Bucket_Access renames Current_Hook.all;

begin
   ...
   Current_Hook := <something else>
   ...
end;


Then Current would still be the same object and value it use to be?

If so, then "renames" isn't quite as simple as I thought. It is more
like a "hard link" then a "symbolic link". i.e. it links to the object
rather then the name of the object. Interesting.

Question: If you freed the value (with unchecked_deallocate) of
"Current_Hook" would the value of "Current" still be valid? I suspect
it would not be valid, as "Current" is now dangling.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Is this a bug?

[Nick Roberts]

Wojtek Narczynski wrote:

> Okay, I wasn't thinking. It obviously isn't a compiler bug.

To clarify (hopefully), there is a line which changes the value of 
Current_Hook:

    Current_Hook := Current_Hook.all.Down'Unchecked_Access;

The value of Current would not have been changed by this statement, so it 
would presumably have been left referring to the wrong thing. The code 
shown is quite complex, and Wojtek can be forgiven for initially missing 
this (in my humble opinion).

-- 
Nick Roberts

Re: Is this a bug?

[Jeff C r e e.m]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message 
news:5ad0dd8a.0409221652.6a69b336@posting.google.com...
> Hello,
>
> GNAT 3.4.2 linux. If I uncomment the Current declaration, and replace
> all occurrences of Current_Hook.all with it, the code does not work
> anymore. Complete runnable testcase available upon request. Is this a
> bug?
>
> Regards,
> Wojtek
>
>

Note I think you mean GCC 3.4.2

GNAT version numbers are disjoint from GCC version numbers and generally 
imply a release (public or otherwise) that originated from Ada Core 
Technologies.

(e.g. GNAT 3.15p, GNAT 5.01a).

The 3.4.2 designation is for GCC (which does not mean GNU C Compiler, it is 
the GNU Compiler Collection). GCC 3.4.2 natively contains Ada support.

Re: Is this a bug?

[Wojtek Narczynski]

Okay, I wasn't thinking. It obviously isn't a compiler bug.

Sorry,
Wojtek

Is this a bug?

[Wojtek Narczynski]

Hello,

GNAT 3.4.2 linux. If I uncomment the Current declaration, and replace
all occurrences of Current_Hook.all with it, the code does not work
anymore. Complete runnable testcase available upon request. Is this a
bug?

Regards,
Wojtek


procedure Put_Last
  (Queue : in out Queue_Type;
   Bucket : out Bucket_Access;
   Element : in Queue_Element_Access;
   Priority : Integer)
is
   Current_Hook : Bucket_Access_Access :=
     Queue.Anchor'Unchecked_Access;
   --  Current : Bucket_Access renames Current_Hook.all;
   --  XXX Uncommented and used - breaks the code
begin
   loop
      if Current_Hook.all = null then
         --  Reached end of list, append bucket
         Current_Hook.all := new Bucket_Type;
         Current_Hook.all.Priority := Priority;
         exit;
      elsif Current_Hook.all.Priority > Priority then
         --  Traverse to the next bucket
         Current_Hook := Current_Hook.all.Down'Unchecked_Access;
      elsif Current_Hook.all.Priority = Priority then
         --  Found bucket with desired pririty
         exit;
      elsif Current_Hook.all.Priority < Priority then
         --  Insert a bucket before current
         declare
            Bucket_New : Bucket_Access := new Bucket_Type;
         begin
            Bucket_New.Down := Current_Hook.all;
            Current_Hook.all := Bucket_New;
            Current_Hook.all.Priority := Priority;
            exit;
         end;
      end if;
   end loop;
   --  Here we are at bucket with correct priority
   Bucket := Current_Hook.all;
   Put_Last (Bucket.all, Element);
end Put_Last;