ADA FUNCTIONS TO PROCEDURES

ADA FUNCTIONS TO PROCEDURES

[Tuan Anh Nguyen]

Hi,
I'm looking for a utility program that would allow me to convert all
functions into procedures.
For example:

functions equal(Left:  in int;
                Right: in int) return Boolean;

in the specification add the following:

procedure equal(Left:   in int;
                Right:  in int;
                Result: in Boolean);

and in the body add the following:


procedure equal(Left:   in int;
                Right:  in int;
                Result: in Boolean) is
begin
   Result := equal(Left,Right);
end equal;


Please email to tanguyen@nps.navy.mil
Thanks

Re: ADA FUNCTIONS TO PROCEDURES

[Robert Dewar]

You may have better luck converting functions to procedures if you make
the result be an OUT parameter :-)

Re: ADA FUNCTIONS TO PROCEDURES

[Robert Dewar]

Can you tell us, just for curiosity, why anyone would want such a tool?
I would be surprised if one exists, because I can't see any legitimate use
for it!

Re: ADA FUNCTIONS TO PROCEDURES

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: ADA FUNCTIONS TO PROCEDURES
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



Robert Dewar <dewar@CS.NYU.EDU> writes:
>
>Can you tell us, just for curiosity, why anyone would want such a tool?
>I would be surprised if one exists, because I can't see any legitimate use
>for it!
>
I'd be inclined to agree, except for one possible issue.
Depending on the compiler, target hardware, etc. it's concievable
that there might be more overhead associated with a function call
than a procedure call. In some applications where you might be
fighting for every microsecond, even a relatively small savings
in overhead might make it worth the effort. That way, you can
program with the "function" call where it makes good programming
sense, yet do a conversion prior to compilation to squeeze a few
extra ergs out of the application.

Of course, I don't know if that's the issue here - just a guess
as to why someone *might* want to find such a tool.

Pax,
Marin
Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    Please send responses to one of the addresses in this trailer.
    A "reply" to the address in the message header will bounce.
===============================================================================
   "If you don't say anything, you won't be called on to repeat it."

        -- Calvin Coolidge
===============================================================================

Re: ADA FUNCTIONS TO PROCEDURES

[Henri Altarac]

CONDIC@PSAVAX.PWFL.COM wrote:
>
> 
> Robert Dewar <dewar@CS.NYU.EDU> writes:
> >
> >Can you tell us, just for curiosity, why anyone would want such a tool?
> >I would be surprised if one exists, because I can't see any legitimate use
> >for it!
> >
> I'd be inclined to agree, except for one possible issue.

I have another possible reason.

In some (strange) coding standard I saw, they required that
function should not have any side effects. Procedure could.

-----
Henri Altarac 

Re: ADA FUNCTIONS TO PROCEDURES

[Pug 156]

I have never seen such a tool.  But, if one were to write it, it would be
required to have the *calling* software submitted to the tool, as well as
the subprograms in question.

Besides the obvious problem of converting the calls from function notation
into procedural,  it would have to be able to "unnest" function calls,
create the necessary temporary variables for each level of unnesting, and
line up the calls to the procedures such that the temporary variables get
populated correctly.  Not a trivial bit of work.  

As I don't really have time to gen up this sort of thing, I suggest a
professor assign it to the class.  Give them access to a parser, so they
don't have to sort that bit out.

Re: ADA FUNCTIONS TO PROCEDURES

[James A. Krzyzanowski]

Henri Altarac (haltarac@rain.org) wrote:
: CONDIC@PSAVAX.PWFL.COM wrote:
: >
: > 
: > Robert Dewar <dewar@CS.NYU.EDU> writes:
: > >
: > >Can you tell us, just for curiosity, why anyone would want such a tool?
: > >I would be surprised if one exists, because I can't see any legitimate use
: > >for it!
: > >
: > I'd be inclined to agree, except for one possible issue.

: I have another possible reason.

: In some (strange) coding standard I saw, they required that
: function should not have any side effects. Procedure could.

: -----
: Henri Altarac 

What's so strange about that?  At Magnavox, we DO have that as a coding
standard!
--
Not necessarily the opinion of the company...
--
---------------------------------------------------------------------------
James A. Krzyzanowski - Senior Software Engineer - AFATDS
Magnavox Electronic Systems Company * Fort Wayne, IN 46808 * (219) 429-6446
jakrzy@most.magec.com        Opinions_Expressed := (Mine and not Magnavox);
            "I'd rather be right than politically correct !!!"
---------------------------------------------------------------------------

Re: ADA FUNCTIONS TO PROCEDURES

[David Weller]

In article <D5Aoy5.JCH@ss3.magec.com>,
James A. Krzyzanowski <jakrzy@ss5.magec.com> wrote:
>Henri Altarac (haltarac@rain.org) wrote:
>
>: In some (strange) coding standard I saw, they required that
>: function should not have any side effects. Procedure could.
>
>What's so strange about that?  At Magnavox, we DO have that as a coding
>standard!

I think he was implying it was strange because it required it in a
strict sense (?).  We have the "No side effect" rule in our standard
too, but it's immediately followed up with a statement that one MAY
break the rule if 1) it provides a more readable product, 2) it is a
"safe" usage ( a good example is the state of a random number
generator), and 3) It passes a code review of peers and at least one
"expert"


-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
	

Re: ADA FUNCTIONS TO PROCEDURES

[Henri Altarac]

dweller@Starbase.NeoSoft.COM (David Weller) wrote:
>
> In article <D5Aoy5.JCH@ss3.magec.com>,
> James A. Krzyzanowski <jakrzy@ss5.magec.com> wrote:
> >Henri Altarac (haltarac@rain.org) wrote:
> >
> >: In some (strange) coding standard I saw, they required that
> >: function should not have any side effects. Procedure could.
> >
> >What's so strange about that?  At Magnavox, we DO have that as a coding
> >standard!
> 
> I think he was implying it was strange because it required it in a
> strict sense (?).  We have the "No side effect" rule in our standard
> too, but it's immediately followed up with a statement that one MAY
> break the rule if 1) it provides a more readable product, 2) it is a
> "safe" usage ( a good example is the state of a random number
> generator), and 3) It passes a code review of peers and at least one
> "expert"
> 

David is correct. The coding standard is was thinking about was 
very poor : nothing was explained/justified and many rules were
to strict and limitative. At the opposite of the SPC guide.

Also I consider any limitation should be automatically verified
by some tool used along the compiler and the side effect rule is
one that is quite hard to implement.

And even then, you always find somebody to work around the rule
like using an automatic tool to transform functions to procedures...

-----
Henri Altarac

Re: ADA FUNCTIONS TO PROCEDURES

[James A. Krzyzanowski]

David Weller (dweller@Starbase.NeoSoft.COM) wrote:
: In article <D5Aoy5.JCH@ss3.magec.com>,
: James A. Krzyzanowski <jakrzy@ss5.magec.com> wrote:
: >Henri Altarac (haltarac@rain.org) wrote:
: >
: >: In some (strange) coding standard I saw, they required that
: >: function should not have any side effects. Procedure could.
: >
: >What's so strange about that?  At Magnavox, we DO have that as a coding
: >standard!

: I think he was implying it was strange because it required it in a
: strict sense (?).  We have the "No side effect" rule in our standard
: too, but it's immediately followed up with a statement that one MAY
: break the rule if 1) it provides a more readable product, 2) it is a
: "safe" usage ( a good example is the state of a random number
: generator), and 3) It passes a code review of peers and at least one
: "expert"

Yes, we do have the same exception; I just did not want to confuse the
discussion with practical facts ;^}
--
Not necessarily the opinion of the company...
--
---------------------------------------------------------------------------
James A. Krzyzanowski - Senior Software Engineer - AFATDS
Magnavox Electronic Systems Company * Fort Wayne, IN 46808 * (219) 429-6446
jakrzy@most.magec.com        Opinions_Expressed := (Mine and not Magnavox);
            "I'd rather be right than politically correct !!!"
---------------------------------------------------------------------------

Re: ADA FUNCTIONS TO PROCEDURES

[Bob Kitzberger]

Before we collectively go off the deep end...

I contacted the original poster -- he wanted to convert functions to
procedures becauase a downstream tool (that appears to parse the
Ada source) can't handle functions.  Nothing sinister, nothing
deeply performance driven...

(and yes, I suggested ASIS, etc.)

--
Bob Kitzberger	        +1 (916) 274-3075	        rlk@rational.com
Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945
  "...the solution to the problem is usually to pee on it"  -- Dave Barry