Re: Parsing Ada?

[Stephen Leake <stephen_leake@stephe-leake.org>]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

>    I want to write a program, which can take a package specification,
>    and generate a driver program for calling all the procedures declared
>    in the public part of the package.
>
>    The intent is that which procedure is called should depend only on
>    the command line arguments passed to the driver program.  The
>    selection should happen by matching names and (apparent) types of
>    command line arguments with names and types of formal parameters of
>    the procedures.
>
> An imagined example:
>
>    package An_Application is
>       procedure Show_Help (Help : Boolean);
>       procedure Run_Interactive;
>    end An_Application;
>
> If the generated driver is executed with a single command line argument
> "--help=true" (or maybe just "--help"?), An_Application.Show_Help should
> be called.  If the driver is executed without any command line
> arguments, An_Application.Run_Interactive should be called.  Otherwise
> the driver should terminate with an appropriate error message.

What if there are more than two procedures? I should thing the driver
command line would be:

    driver "<procedure name>"

> As command line arguments technically always are strings, it is possible
> to have some impractical situations, but I hope to find a sensible way
> to detect this kind of formal parameter "overloading".

Hmm. Unclear requirements are always a problem.

> What I really need is:
>
> + To check that no functions are declared in the public part of the
>   package specification.
>
> + To check that no procedures with "out" or "access" parameters are
>   declared in the public part of the package specification.
>
> + A list of the procedures declared in the public part of the package
>   specification.  Including a list of the formal parameters for each
>   procedure containing:
>
>   - The name of the formal parameter.
>   - The functions to call for converting the formal parameter type to
>     and from type String.
>   - The default value of the formal parameter (if any).
>   - The type of the formal parameter (for generating a useful help/error
>     message).

This is clearly a job for ASIS.

> Using ASIS sounds like an excellent idea.  It would avoid some
> unnecessary restrictions on the input data.  My only argument against
> using ASIS is that I would have to learn it first.

Yes, that can take a while. As an extended example, I suggest SAL
auto_text_io (which I wrote); it does a similar job (examines a package
spec, writes another package spec to do Text_IO for the types in the
first). See http://stephe-leake.org/ada/auto_text_io.html

-- 
-- Stephe