Re: Parsing Ada?

[Jacob Sparre Andersen <sparre@nbi.dk>]

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

> I'm guessing that the actual project requirements do not include
> "write a parser", but rather talk about what information must be
> extracted from the code. The decision to write a parser is a design
> decision. Since that decision seems to be causing problems, it might
> be useful to describe the project more fully, so we can suggest
> alternate solutions.

Correct.

   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.

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".

> You don't describe what information you want to extract from the code,
> so I don't know what features you need in the actions.

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).

The subset I specified earlier was mostly declared to make things easier
for myself, when writing a parser.

> If you are processing compilable Ada code, then ASIS is a good
> approach; the parser is already written and maintained, and you can
> focus on the real project requirements.

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.

The tool is only going to run on "development hosts", so (as a first
approximation) memory and CPU usage does not matter.

> If your project requirements might change in the future to expand the
> subset, then a general parser tool will be easier to adapt than a
> recursive descent design that takes advantage of the subset. Or using
> a full Ada parser in the first place (ie ASIS, or ada-grammar.wy from
> Emacs ada-mode) would be a good idea.

It seems likely that the requirements may change in the future.  I've
already had comments about parsing comments/aspects as help text for the
generated driver.

> If you are required to verify that the source code conforms to the
> subset, then a using a full Ada parser will complicate things; you
> have to explicitly disallow lots of stuff, rather than explicitly
> allowing only the subset.

The actual limitations are quite simple.

> I don't think the choice of parser tool is causing your problem, but
> I'm not sure what your problem is.

Thanks for reminding me about describing the actual problem, and not
just the stone I stumbled over.  :-)

Greetings,

Jacob
-- 
"It is very easy to get ridiculously confused about the tenses of time
 travel, but most things can be resolved by a sufficiently large ego."