Re: Redefining Integer Type ...

Re: Redefining Integer Type ...

[Robert A Duff]

Arnaud de Muyser <ademuyser@attol-testware.com> writes:

> I've a little question about operator "+" resolution into 
> the following pack2-proc.adb procedure.
> Why the resolved type (by gnat) is standard.integer whereas
> the visible type named Integer is pack.integer (using use clause).

Names from outer scopes always take precedence over use-visible names.
Everything is nested within Standard.  So in your example,
Standard.Integer hides Pack.Integer.

I don't like that rule -- it's error prone, as you can see.
Hiding considered harmful.

A good rule of thumb is to never redefine any name (such as Integer)
that is declared in Standard, or *could* be declared in Standard (such
as Long_Long_Long_Long_Long_Integer).

- Bob

Re: Redefining Integer Type ...

[Gautier]

Robert A Duff:

> Names from outer scopes always take precedence over use-visible names.
> Everything is nested within Standard.  So in your example,
> Standard.Integer hides Pack.Integer.
> 
> I don't like that rule -- it's error prone, as you can see.
> Hiding considered harmful.
> 
> A good rule of thumb is to never redefine any name (such as Integer)
> that is declared in Standard, or *could* be declared in Standard (such
> as Long_Long_Long_Long_Long_Integer).

I have tested some time ago "type boolean is (true,false);": different
compilers made it work in differents ways, without warning... :-)

G.

Re: Redefining Integer Type ...

[Pat Rogers]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccn1g2cnfb.fsf@world.std.com...
> Arnaud de Muyser <ademuyser@attol-testware.com> writes:
>
> > I've a little question about operator "+" resolution into
> > the following pack2-proc.adb procedure.
> > Why the resolved type (by gnat) is standard.integer whereas
> > the visible type named Integer is pack.integer (using use clause).
>
> Names from outer scopes always take precedence over use-visible
names.
> Everything is nested within Standard.  So in your example,
> Standard.Integer hides Pack.Integer.
>
> I don't like that rule -- it's error prone, as you can see.
> Hiding considered harmful.

But there is a benefit to the rule that use-visible names don't hide
names that are already visible -- a use clause added later won't
change the meaning of an existing bit of code.  Granted it can be
confusing with the names declared within Standard, but overall it
seems worth the price, especially given that declaring names identical
to those in Standard seems confusing anyway.

---
Patrick Rogers                      Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: Redefining Integer Type ...

[Robert A Duff]

"Pat Rogers" <progers@NOclasswideSPAM.com> writes:

> > I don't like that rule -- it's error prone, as you can see.
> > Hiding considered harmful.
> 
> But there is a benefit to the rule that use-visible names don't hide
> names that are already visible -- a use clause added later won't
> change the meaning of an existing bit of code.

That's exactly my point.  Hiding is Harmful.  The rule about use clauses
is Good, because it does *not* introduce hiding (between use-vis things).
The problem is that nested declarations can hide use-vis things:

    package Parent is
        X: Integer;
    end Parent;
    
    ... -- several levels
    
    package Something_Else is
        X: Integer;
    end Something_Else;

    package Parent.Child.Grandchild.Greatgrandchild is
        use Something_Else;
        ... -- which X is visible here?

The programmer might think it's Something_Else.X, but it's actually
Parent.X.

The good rule about use-clauses should be extended to everything: there
should be no hiding, period.

>...  Granted it can be
> confusing with the names declared within Standard,

Not just Standard, as illustrated above.  Any outer name can hide a
use-visible name, and any outer name can hide an inner name.
Both forms of hiding are bad.

>... but overall it
> seems worth the price, especially given that declaring names identical
> to those in Standard seems confusing anyway.

But the purpose of the rules is to *prevent* confusion!

- Bob

P.S. I hope nobody thinks I'm suggesting changes to Ada.  It can't be
changed in an upward incompatible way.  I'm talking about language
design more generally.

Redefining Integer Type ...

[Arnaud de Muyser]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]


 Hi,

I've a little question about operator "+" resolution into 
the following pack2-proc.adb procedure.
Why the resolved type (by gnat) is standard.integer whereas
the visible type named Integer is pack.integer (using use clause).
The type cast Integer(var) isn't enough ?

I given you the complete source to investigate what appened.

Thanks for the help.

Arnaud de Muyser

[-- Attachment #2: pack.ads --]
[-- Type: text/plain, Size: 87 bytes --]

Package Pack is

  Type Integer is range 1..1000 ;

  current : Integer := 1 ;


End ;

[-- Attachment #3: pack2-proc.adb --]
[-- Type: text/plain, Size: 137 bytes --]


separate( pack2 )
Procedure Proc is
Begin
   for i in 1..10 
   loop
        tab( i + 30*Integer( current)  ) := 1; 
   end loop;
End ;

[-- Attachment #4: pack2.adb --]
[-- Type: text/plain, Size: 131 bytes --]

with Pack; use Pack;

Package Body Pack2 is

  tab : array( 1..Integer(1000) ) of Integer ;

  Procedure proc is separate ;

End ;

[-- Attachment #5: pack2.ads --]
[-- Type: text/plain, Size: 46 bytes --]


Package Pack2 is

  Procedure Proc;

End ;