GNAT-2005

GNAT-2005

[rashmi]

Dear all,

I have a problem with trying to understand GNAT's working for the
following:
________________________________________________________________________________
package PKGE_NasRdFuns is
	function FUNC_ScBAVCk(RE_ScBA : in RE_SclrBA; RE_CtBA : in RE_CatgBA)
return TF_Done;
	function FUNC_ScBAFCk(RE_ScBA : in RE_SclrBA; RE_CtBA : in RE_CatgBA)
return TF_Done;
--	function FUNC_ScP4VCk(RE_ScP4 : in RE_SclrP4; RE_CtP4 : in
RE_CatgP4) return TF_Done;
--	function FUNC_ScP4FCk(RE_ScP4 : in RE_SclrP4; RE_CtP4 : in
RE_CatgP4) return TF_Done;
	function FUNC_BAFDIRd(IN_FL04,IN_FL05,IN_NDim : in Integer) return
RE_BAFDIm;
	function FUNC_BAVCPRd(IN_VC02,IN_VC03 : in Integer) return RE_BAVCPo;
	function FUNC_BAVPLRd(IN_VC04,IN_VC05 : in Integer) return RE_BAVPLn;
	function FUNC_BAVMBRd(IN_VM02,IN_VM03 : in Integer) return RE_BAVMBr;
	function FUNC_BAFPLRd(IN_FF03,IN_FF04 : in Integer) return RE_BAFPLn;
	function FUNC_BAFORRd(IN_FL02,IN_FL03 : in Integer) return RE_BAFORn;
end PKGE_NasRdFuns ;
_____________________________________________________________________________

1. Given above is an ada spec package (.ads) PKGE_NASRdFuns with
specifications for many functions such as FUNC_ScBAVCk, FUNC_ScBAFCk,
etc.
2. Parameters such as RE_ScBA are records defined in another package,
while IN_VC02, IN_VC03 etc. are scalars.
3. I find that if I delete the first few lines that give specs for
FUNC_ScBAVCK or FUNC_ScBAFCk, for which records are parameters, and
then compile the package's body (.adb), GNAT does not report that
functions are undefined. On the other hand, if I delete a specs line
such as that for FUNC_BAVCPRd for which scalars are parameters, GNAT
immediately reports "function FUNC_BAVCPRd undefined" when I compile
the body.

I want to understand why GNAT has such a strange response, that is, why
it does not report "function undefined" for the former case.

Thanks in advance.
Rashmi.

Re: GNAT-2005

[Georg Bauhaus]

On Thu, 2006-11-09 at 22:51 -0800, rashmi wrote:
> Dear all,
> 
> I have a problem with trying to understand GNAT's working for the
> following:
> ________________________________________________________________________________
> package PKGE_NasRdFuns is
> 	function FUNC_ScBAVCk(RE_ScBA : in RE_SclrBA; RE_CtBA : in RE_CatgBA)
> return TF_Done;
> 	function FUNC_ScBAFCk(RE_ScBA : in RE_SclrBA; RE_CtBA : in RE_CatgBA)
> return TF_Done;
> --	function FUNC_ScP4VCk(RE_ScP4 : in RE_SclrP4; RE_CtP4 : in
> RE_CatgP4) return TF_Done;
> --	function FUNC_ScP4FCk(RE_ScP4 : in RE_SclrP4; RE_CtP4 : in
> RE_CatgP4) return TF_Done;
> 	function FUNC_BAFDIRd(IN_FL04,IN_FL05,IN_NDim : in Integer) return
> RE_BAFDIm;
> 	function FUNC_BAVCPRd(IN_VC02,IN_VC03 : in Integer) return RE_BAVCPo;
> 	function FUNC_BAVPLRd(IN_VC04,IN_VC05 : in Integer) return RE_BAVPLn;
> 	function FUNC_BAVMBRd(IN_VM02,IN_VM03 : in Integer) return RE_BAVMBr;
> 	function FUNC_BAFPLRd(IN_FF03,IN_FF04 : in Integer) return RE_BAFPLn;
> 	function FUNC_BAFORRd(IN_FL02,IN_FL03 : in Integer) return RE_BAFORn;
> end PKGE_NasRdFuns ;
> _____________________________________________________________________________
> 
> 1. Given above is an ada spec package (.ads) PKGE_NASRdFuns with
> specifications for many functions such as FUNC_ScBAVCk, FUNC_ScBAFCk,
> etc.
> 2. Parameters such as RE_ScBA are records defined in another package,
> while IN_VC02, IN_VC03 etc. are scalars.
> 3. I find that if I delete the first few lines that give specs for
> FUNC_ScBAVCK or FUNC_ScBAFCk, for which records are parameters, and
> then compile the package's body (.adb), GNAT does not report that
> functions are undefined. On the other hand, if I delete a specs line
> such as that for FUNC_BAVCPRd for which scalars are parameters, GNAT
> immediately reports "function FUNC_BAVCPRd undefined" when I compile
> the body.

Just a guess, without seeing the package body:
Are there function bodies in the package body that call
the functions you deleted from the spec (only)? In this case
the compiler may know a function because it is still defined
in the body before it is used, but does not know some other
function that is used before it is defined later in the body.


-- Georg 

Re: GNAT-2005

[Stephen Leake]

"rashmi" <rashmi.thoras@gmail.com> writes:

> I have a problem with trying to understand GNAT's working for the
> following:
><snip spec>

> 3. I find that if I delete the first few lines that give specs for
> FUNC_ScBAVCK or FUNC_ScBAFCk, for which records are parameters, and
> then compile the package's body (.adb), GNAT does not report that
> functions are undefined. On the other hand, if I delete a specs line
> such as that for FUNC_BAVCPRd for which scalars are parameters, GNAT
> immediately reports "function FUNC_BAVCPRd undefined" when I compile
> the body.

Without seeing the body, it's impossible to say.

Most likely the bodies of the "scalar functions" are present in the
package body _before_ the places they are called. 

-- 
-- Stephe

Re: GNAT-2005

[Wilhelm Spickermann]

Hi,

rashmi wrote:

> I want to understand why GNAT has such a strange response, that
> is, why it does not report "function undefined" for the former
> case.

Perhaps you misunderstood the purpose of the ads-file. It only
defines the interface to the outside world and not everything
that is needed in the body. Functions which are not mentioned in
the ads-file but defined in the adb-file are not undefined; they
are defined and can be used in the body. They are just not part
of the services provided to the rest of the world.

Wilhelm

Re: GNAT-2005

[Adam Beneschan]

Stephen Leake wrote:
> "rashmi" <rashmi.thoras@gmail.com> writes:
>
> > I have a problem with trying to understand GNAT's working for the
> > following:
> ><snip spec>
>
> > 3. I find that if I delete the first few lines that give specs for
> > FUNC_ScBAVCK or FUNC_ScBAFCk, for which records are parameters, and
> > then compile the package's body (.adb), GNAT does not report that
> > functions are undefined. On the other hand, if I delete a specs line
> > such as that for FUNC_BAVCPRd for which scalars are parameters, GNAT
> > immediately reports "function FUNC_BAVCPRd undefined" when I compile
> > the body.
>
> Without seeing the body, it's impossible to say.
>
> Most likely the bodies of the "scalar functions" are present in the
> package body _before_ the places they are called.

That seems most likely to me, too.

Things have to be declared before they can be used (with few
exceptions).  When you call one of these functions in the body, the
compiler has to have seen it previously---either in the spec, or
earlier in the body.  If you remove the declaration of a function from
the spec, it's still OK to call it IF it is defined in the body before
it's used---but not if it's defined in the body after it's used.  So
that's probably why you're getting errors in some cases but not others.

                             -- Adam

Re: GNAT-2005

[Martin Krischik]

Adam Beneschan wrote:

> Stephen Leake wrote:
>> "rashmi" <rashmi.thoras@gmail.com> writes:
>>
>> > I have a problem with trying to understand GNAT's working for the
>> > following:
>> ><snip spec>
>>
>> > 3. I find that if I delete the first few lines that give specs for
>> > FUNC_ScBAVCK or FUNC_ScBAFCk, for which records are parameters, and
>> > then compile the package's body (.adb), GNAT does not report that
>> > functions are undefined. On the other hand, if I delete a specs line
>> > such as that for FUNC_BAVCPRd for which scalars are parameters, GNAT
>> > immediately reports "function FUNC_BAVCPRd undefined" when I compile
>> > the body.
>>
>> Without seeing the body, it's impossible to say.
>>
>> Most likely the bodies of the "scalar functions" are present in the
>> package body _before_ the places they are called.
> 
> That seems most likely to me, too.
> 
> Things have to be declared before they can be used (with few
> exceptions).  When you call one of these functions in the body, the
> compiler has to have seen it previously---either in the spec, or
> earlier in the body.  If you remove the declaration of a function from
> the spec, it's still OK to call it IF it is defined in the body before
> it's used---but not if it's defined in the body after it's used.  So
> that's probably why you're getting errors in some cases but not others.

Indeed, gnat with full warnings will actually create a warning if the
function only has a body but is not defined - either in the spec or earlier
in the body. This goes well with the gnat style checks which demand bodies
to be sorted.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: GNAT-2005

[Simon Wright]

Martin Krischik <krischik@users.sourceforge.net> writes:

> This goes well with the gnat style checks which demand bodies
> to be sorted.

I'm pretty sure that's not included in -gnaty -- hmm, it's -gnatyo, in
GPL-2006 -gnaty is the same as -gnaty3abcefhiklmnprst.

I've just spotted -gnatyu -- check no unneccessary blank lines -- now
there's something to have a style war about!

Re: GNAT-2005

[Jean-Pierre Rosen]

Simon Wright a �crit :

> I've just spotted -gnatyu -- check no unneccessary blank lines -- now
> there's something to have a style war about!

Of course, it is also one of the many checks that AdaControl can perform!
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GNAT-2005

[Georg Bauhaus]

On Mon, 2006-11-13 at 20:35 +0000, Simon Wright wrote:

> I've just spotted -gnatyu -- check no unneccessary blank lines -- now
> there's something to have a style war about!

Yeah. War against egalitarianism! Different uniforms in different
schools, or else style fighters can't recognize their enemy  :-)

Of course, it does help if a program is suitably dressed.
Tailor Pretty's art will help us to smooth out whatever
rough edges our programs must inevitably show. This is both
marketing, and also an important social issue.

I wish we had a switch that generates style setups paying attention
to today's output media. These generate a rather diverse set of
appearances even with the same style options set.
Most of us don't use typewriters any more. Hence,
what's the point of defining rules about white space, paren offsets,
and other cosmetic issues when your frame of reference is the fixed
width character model which does *not* specify the effects of
choosing this or that font, color, thickness, etc.?

By analogy, how about a rule stating that names should be red,
keywords should be green.....

When I open a light blue xterm and connect to some GNU/Linux
machine it is likely that I see the effects of
alias ls='ls --color=auto'
That is, directory names printed in light blue on light blue...
--auto does not automatically adapt to the terminal setting,
but this is where it prints its output.

I'm happy to find the "end if" belonging to in "if" aligned
with that "if", even when the "end if" appears after an
unnecessary empty line. Whatever color, font or parenthesis
spacing is in effect.

Georg 
Anyone in favor of -gnatyT, check no unnecessary title boxes? ;-)

Re: GNAT-2005

[Björn Persson]

Simon Wright wrote:
> I've just spotted -gnatyu -- check no unneccessary blank lines -- now
> there's something to have a style war about!

Hmmmm, so where in the Ada syntax is a blank line necessary?

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: GNAT-2005

[Pascal Obry]

Simon Wright a �crit :
> I've just spotted -gnatyu -- check no unneccessary blank lines -- now
> there's something to have a style war about!

Well we can like or dislike this kind of rules, no problem. The
important point to me is to ensure that an application code is uniform
whatever the style chosen. This way all developers feel comfortable with
all part of the application. And no code belongs to a single developer.

Avoiding multiple blank lines help in this direction.

Just my 2 cents,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT-2005

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> Simon Wright a �crit :
>> I've just spotted -gnatyu -- check no unneccessary blank lines --
>> now there's something to have a style war about!
>
> Well we can like or dislike this kind of rules, no problem. The
> important point to me is to ensure that an application code is
> uniform whatever the style chosen. This way all developers feel
> comfortable with all part of the application. And no code belongs to
> a single developer.

I completely agree about uniformity. We chose to compile with -gnaty
for exactly this reason.

I think the thing that annoys me most is a developer who doesn't have
a consistent style at all; indentation all over the shop, FunkyCaps on
one line, lower_Case on the next ...

Personally I find that blank lines are good within a non-tiny
subprogram, and then _double_ blank lines between subprograms (which
this style check forbids). So I'm glad that -gnatyu is not part of the
default set picked up by -gnaty.

There was a lot to be said for the old Rational Environment, where the
developer had hardly any control over the layout. Is Apex the same?