Re: Parsing Ada?

[jan.de.kruyf@gmail.com]

On Thursday, June 4, 2015 at 2:15:51 PM UTC+2, jan.de...@gmail.com wrote:
> 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.

Here you will find the book, section 7.1 describes the scanner. OSS.Mod is the scanner source code for this specific implementation.

http://www.inf.ethz.ch/personal/wirth/CompilerConstruction/

j