Re: calling function inside procedure call

[Shark8 <OneWingedShark@gmail.com>]

On 10/3/2014 6:07 PM, Stribor40 wrote:
> On Friday, 3 October 2014 16:42:43 UTC-4, Marius Amado-Alves  wrote:
>> Did you know you can declare local procedures as you do functions?
>
> no.....how would that be done and what would be the benefits?

Well consider something kinda complex, say parsing:
  You have a function Parse which takes a string and parses it into a 
type containing several components:

   subtype String_4 is String(1..4);

   Type Some_Record is record
    A, B : Integer;
    C    : Boolean;
    D    : String_4;
   end record;

  -- ...
  Parse_Error : Exception;
  Function Parse( Input : String ) return Some_Record;

  -- in the body...

  Function Parse( Input : String ) return Some_Record is
     Working	: Ada.Strings.Unbounded.Unbounded_String:=
                   Ada.Strings.Unbounded.To_Unbounded_String(Input);

     -- All Get_Segment functions consume the front-end of Working
     Function Get_Segment return Integer;
     Function Get_Segment return Boolean;
     Function Get_Segment return String_4;

     -- IMPLEMENTATIONS OF GET_SEGMENT GO HERE.

  begin
    return Some_Record'(
         A => Get_Segment,
         B => Get_Segment,
         C => Get_Segment,
         D => Get_Segment
       );
  end Parse;

As you can see, this turns the actual body portion of the parsing into 
something quite small: a single statement. (I could have put it all on 
one line.) This method allows you to compose the parse function of 
smaller functions, functions which are not visible [or accessible] 
outside of the scope of the function. This means you can contain things, 
and you will be able to change them freely as you are guaranteed that 
these nested functions will not be used elsewhere.



> i am still having troubles figuring out when to use function and when to use procedure

Simple rule: does it return a value? If so it's a function, if not 
procedure. (Yes, the IN OUT and OUT modes on procedures muddy things a 
little, as does allowing functions to have OUT and IN OUT modes; don't 
worry about these too much.)

> As of right now on my baby steps in ada i base it on if i need to return something or not.

That's generally the correct approach.
There are some subtleties, like constrained and unconstrained [sub]types 
that change things: if you're returning an unconstrained type it /must/ 
be a function. -- But that can, and should, wait until you get 
comfortable with constrained/unconstrained.