Re: Parsing Ada?

[jan.de.kruyf@gmail.com]

On Thursday, June 4, 2015 at 8:59:58 AM UTC+2, Jacob Sparre Andersen wrote:

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

hallo,
It seems to me that the trick is in the right "scanner" to find the keywords you need.
Then the parsing will follow as Dmitry described.
I did use this in the past:

https://launchpad.net/adascan

But I did find that, although its simple, I preferred to roll my own for fine control. (But then I am a simple soul that prefers small languages :) 
I came to 44k of source, including the generic part from Rubini, Which I had to inspect closely in order to adapt it in a very small way. 
My version recognizes all of 13 tokens of a configuration file, But the Rubini part is quite general and presumably should scan Ada well.

For a scanner following the Wirth compiler book I came to 39k source (in Ada) for about 150 - 200 key words.
 And I came to 40k for the parser. This was for the binary machine file of a CAM language called APT, designed in the days that FORTRAN was king. 
Anything beyond that is of no real interest, its just what I did with it.


To just find and parse procedure / function specs is quite fast I would say. Faster than anything off the shelf. To find and parse the details of any custom made type will be painful though, whatever solution you choose.

Hope this helps

j.