Parsing Ada?

Parsing Ada?

[Jacob Sparre Andersen]

I have a project, which requires that I write/generate a parser for an
Ada subset:

+ Only package specifications.
+ No use clauses.
+ No type, object or function declarations (only procedures).
+ Procedures can only have "in" parameters.

I have attempted to use OpenToken to do the parsing, and although it
seems to work fine as a parser, the options for extracting information
from the parse tree are too limited (or maybe I just can't understand
the documentation).

I'm not that fond of generating the parser on-the-fly every time I run
my program.  I would prefer to compile the grammar to Ada source text,
which I then could compile into the program.

What open source parsers/parser generators are there for use in Ada
programs?  And what are your experiences with them?

So far I've found:

+ OpenToken
+ AdaGOOP
+ ayacc

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

Re: Parsing Ada?

[G.B.]

On 02.06.15 13:33, Jacob Sparre Andersen wrote:
> I have a project, which requires that I write/generate a parser for an
> Ada subset:

Wouldn't that be a job for an ASIS program?

> + OpenToken
> + AdaGOOP
> + ayacc

The Coco/R page lists a version for Ada,
http://www.ssw.uni-linz.ac.at/Coco/

Re: Parsing Ada?

[Jacob Sparre Andersen]

G.B. <bauhaus@futureapps.invalid> wrote:
> On 02.06.15 13:33, Jacob Sparre Andersen wrote:

>> I have a project, which requires that I write/generate a parser for
>> an Ada subset:
>
> Wouldn't that be a job for an ASIS program?

It might be a solution, yes.

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

Re: Parsing Ada?

[Luke A. Guest]

"G.B." <bauhaus@futureapps.invalid> wrote:
> On 02.06.15 13:33, Jacob Sparre Andersen wrote:
>> I have a project, which requires that I write/generate a parser for an
>> Ada subset:
> 
> Wouldn't that be a job for an ASIS program?
> 
>> + OpenToken
>> + AdaGOOP
>> + ayacc
> 
> The Coco/R page lists a version for Ada,
> http://www.ssw.uni-linz.ac.at/Coco/

I found that the other day too, but you can't use attributes in the
grammar, it messes with the grammar parser.

Re: Parsing Ada?

[Dmitry A. Kazakov]

On Tue, 02 Jun 2015 13:33:07 +0200, Jacob Sparre Andersen wrote:

> I would prefer to compile the grammar to Ada source text,
> which I then could compile into the program.

That is the core of the problem, then. Why would you do such thing? To
parse Ada you only need a recursive descent parser which is a couple of
hours to write.

> What open source parsers/parser generators are there for use in Ada
> programs?  And what are your experiences with them?

I never bothered to write an Ada program parser because I considered it
trivial. All small compilers I wrote, from some very strange languages used
in automation, are recursive descent plus expression parser (if necessary).

This goes for each case statement at each level of the recursive descent
parser:

http://www.dmitry-kazakov.de/ada/components.htm#12.4.4

I don't know how many would be, a half of dozen, I suppose. Ada is a well
structured regular language.

This is for getting/skipping an expression:

http://www.dmitry-kazakov.de/ada/components.htm#12.9

This is to skip blanks in the source:

http://www.dmitry-kazakov.de/ada/components.htm#12.4.2

That's it. No structures/trees ever needed unless you generate them
yourself.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Parsing Ada?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:7cpxfz18lg2r$.ymcopru7qn8x.dlg@40tude.net...
> On Tue, 02 Jun 2015 13:33:07 +0200, Jacob Sparre Andersen wrote:
>
>> I would prefer to compile the grammar to Ada source text,
>> which I then could compile into the program.
>
> That is the core of the problem, then. Why would you do such thing? To
> parse Ada you only need a recursive descent parser which is a couple of
> hours to write.

There's a lot more to the equation than a parse, though. And if you can 
write a correct recursive descent parser for all of Ada in a "couple of 
hours", you're a genius *and* can type at an inhuman rate. It took me more 
than 80 hours to just add the Ada 2012 changes to our existing grammar (a 
lot of that time was keeping the existing stuff from breaking, of course; 
aspect specifications were particularly bad that way, because they are added 
on the right and thus all of the parse stack offsets changed when they were 
added).

One thing is if the target is small (not sure why it would be in this case, 
but anyway), a table-driven parser can be many times smaller. Back in the 
day, I tested redoing our compiler as a recursive descent, and it would have 
been roughly 10 times larger than the table-driven parser (code+table). That 
mattered a lot on the original Z80 compiler; we only had 48K RAM to fit the 
entire parser/lexer, and the vast majority of that space was needed for the 
identifier/reserved word tables, and the string literal tables. Our original 
table-driven parser fit in less than 4K, so that left a lot of room for the 
other stuff. The sample recursive descent parser was over 16K before I gave 
up on it as impractical. (Note that I'm only talking about the parser; the 
lexer was exactly the same for either, and the action routines are 
essentially the same either way.)

Obviously, if you're parsing a small subset of Ada (as appears to be the 
case here), and the target size doesn't matter (likely), then recursive 
descent is probably the best choice. (Using ASIS seems like madness to me, 
unless you intend to use a significant part of the semantic analysis. For 
purely parsing, it's much more work to get information out of ASIS than it 
would be to just parse the text yourself.

                                    Randy. 

Re: Parsing Ada?

[Dmitry A. Kazakov]

On Wed, 3 Jun 2015 17:39:40 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:7cpxfz18lg2r$.ymcopru7qn8x.dlg@40tude.net...
>> On Tue, 02 Jun 2015 13:33:07 +0200, Jacob Sparre Andersen wrote:
>>
>>> I would prefer to compile the grammar to Ada source text,
>>> which I then could compile into the program.
>>
>> That is the core of the problem, then. Why would you do such thing? To
>> parse Ada you only need a recursive descent parser which is a couple of
>> hours to write.
> 
> There's a lot more to the equation than a parse, though. And if you can 
> write a correct recursive descent parser for all of Ada in a "couple of 
> hours", you're a genius *and* can type at an inhuman rate.

No for all Ada of course, only for the things which are neither expressions
(including fully qualified names) nor comments. It would be insane to use a
recursive descent parser for expressions. But the result would be a full
Ada parser.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Parsing Ada?

[Stephen Leake]

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

> I have a project, which requires that I write/generate a parser for an
> Ada subset:

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.

> + Only package specifications.
> + No use clauses.
> + No type, object or function declarations (only procedures).
> + Procedures can only have "in" parameters.
>
> I have attempted to use OpenToken to do the parsing, and although it
> seems to work fine as a parser, the options for extracting information
> from the parse tree are too limited (or maybe I just can't understand
> the documentation).

OpenToken does not generate a parse tree; you have to do that yourself
(if you actually need a tree) in either the tokens or the actions.

The OpenToken documentation is definitely lacking. The examples can be
helpful.

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.

> I'm not that fond of generating the parser on-the-fly every time I run
> my program.  I would prefer to compile the grammar to Ada source text,
> which I then could compile into the program.

Original OpenToken provides a way to represent a grammar as Ada source. It
then generates the LALR parse tables at runtime; that is a burden on the
target system.

OpenToken wisi-generate represents the grammar in something close to
BNF, and then generates Ada code that represents the parse tables
directly.

One advantage of original OpenToken is that it is easy to specify
actions in Ada, with full access to the parsed tokens as they are
produced. With wisi-generate, it is not as easy to write appropriate
actions (what you want is almost definitely not directly supported by
wisi-generate at the moment).

> What open source parsers/parser generators are there for use in Ada
> programs?  And what are your experiences with them?

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.

Note that ASIS does not produce a parse tree either; it just gives you
structured access to the source. ASIS code tends to feel like a
recursive descent parser (at least, for the tools I've written in ASIS).

AdaControl (http://www.adalog.fr/en/adacontrol.html) provides a large
set of tools built on top of ASIS that you might find useful.

> So far I've found:
>
> + OpenToken
> + AdaGOOP
> + ayacc

I have not tried AdaGOOP.

ayacc is no longer maintained, and appears to be a simple translation of
C yacc (and thus hard to maintain!). It also does not generate a parse
tree for you; you have to provide the actions that do what you want.

As Dmitry points out, writing a recursive descent parser for a subset of
Ada should not be hard. More general parser tools are useful when you
need a parser quickly, or for grammars produced by others (that's my
goal with the Emacs package I'm working on).

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.

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.

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

-- 
-- Stephe

Re: Parsing Ada?

[J-P. Rosen]

Le 03/06/2015 09:58, Stephen Leake a écrit :
> As Dmitry points out, writing a recursive descent parser for a subset of
> Ada should not be hard.
But there is a lot more than parsing if you want to do any serious
analysis of Ada code. Consider:

A(B)

This could be a function call, an array indexing, an indexing of an
implicit dereference, an indexing of the result of a (parameterless)
function call... Sorting that out requires full overloading resolution -
a lot harder than parsing.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Parsing Ada?

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Note that ASIS does not produce a parse tree either; it just gives you
> structured access to the source. ASIS code tends to feel like a
> recursive descent parser (at least, for the tools I've written in
> ASIS).

You might find ASIS2XML[1] helpful (it doesn't attempt to retain
comments, and really only retains textual information (that is, it
retains the name in an entity reference but not the links to the
referenced entity). Also, could do some cleanup of compound identifiers
- it retains the ASIS structure; so "with Ada.Characters.Handling;"
becomes

      <with_clause>
        <selected_component>
          <selected_component>
            <identifier>Ada</identifier>
            <identifier>Characters</identifier>
          </selected_component>
          <identifier>Handling</identifier>
        </selected_component>
      </with_clause>

Also Avatox[2].

The ASIS GPL 2014 source distribution contains a tool gnat2xml which
doesn't appear to be installed automatically. I didn't like the schema
very much, can't remember why now!

You'd probably use xslt to work with the generated XML.

[1] https://sourceforge.net/projects/asis2xml/
[2] Original site unavailable. See the ASIS GPL 2014 distro,
    tools/gnat2xml for READMEs; I have a copy of avatox-1.8.tgz if you
    want.

Re: Parsing Ada?

[Jacob Sparre Andersen]

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

Re: Parsing Ada?

[J-P. Rosen]

Le 04/06/2015 08:59, Jacob Sparre Andersen a écrit :
> 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).
> 
That clearly looks like a job for ASIS. You can easily do that, with
full overloading and type resolution.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Parsing Ada?

[jan.de.kruyf]

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.

Re: Parsing Ada?

[jan.de.kruyf]

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

Re: Parsing Ada?

[Simon Wright]

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

>   - The functions to call for converting the formal parameter type to
>     and from type String.

This is going to be tricky to automate!

It's not directly related, but you might be interested in my Scripted
Testing package[1]. It's really aimed at a design involving code
generation, at least of frameworks[2], where the software under test is
built on lower-level "domains", which can be automatically generated as
stubs, and results in a Tcl interpreter which extends the Tcl language
with application-related commands. As an example of a script (much more
verbose than would be usual!) see [3].

I can thoroughly recommend a scripted approach to testing, at the point
where you're doing black-box testing of functionality; it's very easy to
generate a test case that demonstrates a reported failure and can then
be used to confirm the correction.

[1] https://sourceforge.net/projects/scriptedtesting.coldframe.p/
[2] http://coldframe.sourceforge.net/coldframe/stubs.html
[3] https://sourceforge.net/p/coldframe/code/ci/default/tree/examples/h.tcl

Re: Parsing Ada?

[Jacob Sparre Andersen]

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

>>   - The functions to call for converting the formal parameter type to
>>     and from type String.
>
> This is going to be tricky to automate!

My original plan was to require the existence of Image and Value
functions declared in the same package as the types.

But if I go for ASIS, I expect that I can check if the types have Image
and Value functions as primitive operations, or have 'Image and 'Value
attributes.  If neither is the case, I can report the error already
while analysing the package specification, instead of leaving it to the
compiler to complain, when compiling the generated driver.

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

Re: Parsing Ada?

[Stephen Leake]

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

Re: Parsing Ada?

[Jacob Sparre Andersen]

Stephen Leake wrote:

> What if there are more than two procedures? I should thing the driver
> command line would be:
>
>     driver "<procedure name>"

That is definitely not my plan.  The intent is to select procedures only
based on match between their profiles and the passed command line
arguments.

I can see the point in your suggestion, but it is not how I intend to do
it.  I did consider implementing the classical Unix trick, where the
name of the executable selects the available functionality, but I'm not
sure it is worth doing.

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

Re: Parsing Ada?

[wowwomenonwheels205]

Postal Lottery: Turn $6 into $60,000 in 90 days, GUARANTEED

I found this in a news group and decided to try it. A little while
back, I was browsing through newsgroups, just like you are now and
came across a message just like this that said you could make
thousands of dollars within weeks with only an initial investment of
$6.00!!!

So I thought yeah right, this must be a scam!!! But like most of us, I
was curious, so I kept reading. Anyway, it said that you send $1.00 to
each of the 6 names and addresses stated in the message. You then
place your own name and address at the bottom of the list at #6 and
post the message in at least 200 news groups. (There are thousands to
choose from). No catch, that was it.

So after thinking it over, and talking to a few people first. I
thought about trying it. I figured, what have I got to lose except 6
stamps and $6.00, right? So I invested the measly $6.00!!! Guess what?
Within 7 days I started getting money in the mail!!! I was shocked!!!
I figured it would end soon, but the money just kept coming in!!! In
my first week, I had made about $25.00. By the end of the second week,
I had made a total of over $1,000.00!!! In the third week, I had over
$10,000.00 and it is still growing!!! This is now my fourth week and I
have made a total of just over $42,000.00 and it is still coming in
rapidly!!! It's certainly worth $6.00 and 6 stamps!!! I have spent
more than that on the lottery!!!

Let me tell you how this works and most importantly, why it works!!!

Also, make sure you print a copy of this message now. So you can get
the information off of it as you need it. I promise you that if you
follow the directions exactly, that you will start making more money
than you thought possible by doing something so easy!!!

Suggestion: Read this entire message carefully!!! (Print it out or
download it.) Follow the simple directions and watch the money come
in!!! It's easy!!! It's legal!!! Your investment is only $6.00 (plus
postage).

IMPORTANT: This is not a rip-off!!! It is not illegal!!! ? It is
almost entirely risk free and it really works!!! If all of the
following instructions are adhered to, you will receive extraordinary
dividends!!!

Please note: Follow these directions EXACTLY, and $60,000.00 or more
can be yours in 20 to 90 days!!! This program remains successful
because of the honesty and the integrity of the participants!!! Please
continue its success by carefully adhering to the instructions.

You will now become part of the mail order business. In this business
your product is not solid or tangible, it is a service. You are in the
business of developing mailing lists. Many large corporations are
happy to pay big bucks for quality lists. However, the money made from
a mailing list is secondary to the income which is made from people
like you and me asking to be included on your mailing list!!!

Here are the 4 easy steps to success:-

Step 1:- Get 6 separate pieces of paper and write the following on
each piece of paper.

PLEASE PUT ME ON YOUR MAILING LIST

Now get 6 U.S. dollar bills and place ONE inside each of the 6 pieces
of paper so the bills will not be seen through the envelopes (to
prevent mail theft). Next, place one paper in each of the 6 envelopes
and seal them, you should now have 6 sealed envelopes. Each with a
piece of paper stating the above phrase, your name and address, and a
$1.00 bill.

THIS IS ABSOLUTELY LEGAL!!! YOU ARE REQUESTING A LEGITIMATE SERVICE
AND YOU ARE PAYING FOR IT!!!

Like most of us, I was a little skeptical and a little worried about
the legal aspect of it all. So I checked it out with the U.S. Postal
Service and they confirmed that it is indeed legal!!!

Mail the 6 envelopes to the following addresses:-
D. Kumar
Room 2.36 Burkhardt House
Oxford Place, Victoria Park
M14 5RR Manchester
ENGLAND

T. Perce
11505 Headley Avenue
Cleveland, Oh 44111

T. Beckers
Rijksweg 46
6267AH Cadier en Keer
The Netherlands

J. Eddolls
144 Pursey Drive
Bradley Stoke
Bristol
BS32 8DP
United Kingdom

Louis Joseph
1933 Highway 35, #104
Wall, NJ 07719

Jesse Quiroz
2845 Franklin #1001 
Mesquite, Texas 75150

Step 2:- Now take the #1 name off the list that you see above, move
the other names up (6 becomes 5, 5 becomes 4, etc.) and add your name
as number 6 on the list.

Step 3:- Change anything you need to, but try to keep this message as
close to what you see as possible. Now, post your amended message to
at least 200 news groups. I think there are close to 24,000 groups!!!
All you need is 200, but remember, the more you post, the more money
you make!!! This is perfectly legal!! If you have any doubts, refer to
Title18 Sec. 1302 & 1341 of the postal lottery laws. Keep a copy of
these steps for yourself and whenever you need money, you can use it
again.

Please remember that this program remains successful because of the
honesty and the integrity of the participants and by their carefully
adhering to the directions!!!

Look at it this way. If you are of integrity, the program will
continue and the money that so many others have received will come
your way!!!

Note: - You may want to retain every name and address sent to you,
either on your computer or hard copy and keep the notes people send
you. This verifies that you are truly providing a service. Also, it
might be a good Idea to wrap the $1 bills in dark paper to reduce the
risk of mail theft.

So, as each post is downloaded and the directions carefully followed,
six members will be reimbursed for their participation as a list
developer with one dollar each. Your name will move up the list
geometrically so that when your name reaches the #1 position, you will
be receiving thousands of dollars in cash!!! What an opportunity for
only $6.00!!! ($1.00 for each of the first six people listed above).

Send it now, add your own name to the list and your in business!!!


DIRECTIONS FOR HOW TO POST TO A NEWS GROUP!!!

Step 1:- You do not need to re-type this entire message to do your own
posting. Simply put your cursor at the beginning of this message and
drag your cursor to the bottom of this message and select copy from
the edit menu. This will copy the entire message into the computer
memory.

Step 2:- Open a blank note pad file and place your cursor at the top
of the blank page. From the edit menu select paste. This will paste a
copy of the message into notepad so that you can add your name to the
list.

Step 3:- Save your new notepad file as a txt file. If you want to do
your posting in a different setting, you'll always have this file to
go back to.

Step 4:- Use Netscape or Internet Explorer and try searching for
various news groups (on-line forums, message boards, chat sites,
discussions, etc.)

Step 5:- Visit these message boards and post this message as a new
message by highlighting the text of this message from your notepad and
selecting paste from the edit menu. Fill in the subject, this will be
the header that everybody sees as they scroll through the list of
postings in a particular group. Click the post message button. You've
done your first one! Congratulations!!! All you have to do is jump to
different news groups and post away, after you get the hang of it, it
will take about 30 seconds for each news group!

REMEMBER, THE MORE NEWS GROUPS YOU POST IN, THE MORE MONEY YOU WILL
MAKE!!! (But you have to post a minimum of 200).

That's it!!! You will begin receiving money from around the world
within days!!! You may eventually want to rent a P.O. Box due to the
large amount of mail you will receive. If you wish to stay anonymous,
you can invent a name to use, as long as the postman will deliver it.

JUST MAKE SURE ALL THE ADDRESSES ARE CORRECT!!!

Now the why part. Out of 200 postings, say you receive only 5 replies
(a very low example). So then you made $5.00 with your name at #6 on
the letter. Now, each of the 5 persons who sent you $1.00 make the
minimum 200 postings, each with your name at #5 and only 5 persons
respond to each of the original 5, that is another $25.00 for you. Now
those 25 each make 200 MINIMUM posts with your name at #4 and only 5
replies each, you will bring in an additional $125.00!!! Now, those
125 persons turn around and post the minimum 200 with your name at #3
and only receive 5 replies each, you will make an additional
$625.00!!! OK, now here is the fun part, each of those 625 persons
post a minimum 200 messages with your name at #2 and they each only
receive 5 replies, that
just made you $3,125.00!!! Those 3,125 persons will all deliver this
message to 200 news groups. If just 5 more reply you will receive
$15,625.00!!! All with an original investment of only $6.00!!! Amazing
isn't it!!!! When your name is no longer on the list, you just take
the latest posting in the news groups and send out another $6.00 to
the names on the list, putting your name at number 6 again.

You must realize that thousands of people all over the world are
joining the internet and reading these messages every day!!! Just like
you are now!!! So, can you afford $6.00 and see if it really works?
I'm glad I did!!! People have said, "what if the plan is played out
and no one sends you the money?" So what!!! What are the chances of
that happening, when there are tons of new honest users and new honest
people who are joining the internet and news groups everyday and are
willing to give it a try? Estimates are at 20,000 to 50,000 new users,
every day!!!

REMEMBER PLAY HONESTLY AND FAIRLY AND THIS WILL REALLY WORK!!!

-- Comments/Feedback (please post your feedback/experiences here) --

Not bad for 1 hr's work....made me around $5320 in roughly 35 days
Anthony M - TX

Hello, I rcvd 269 bucks in the post in 2 weeks.
Dan Miami - FL

I had to wait around 10 days before I had any results - $13,450 as of
3rd Jan 2003 to date (14th Feb 2003).Am gonna re-post it again for
more money!!
Del from Alberta - Canada

Only received around  588 in the post the last 2 months since I
started the program but I'd posted to approx. 100 newsgroups.
James P - Manchester, UK

Cool....didn't expect much out of this "scam" initially but I have pay
my credit card bill
Mustafa - Jordan

For $6,I made $246 in 2 weeks
ROMEO2326 - Little Rock, AR -US of A

Hey, just droppin a line to say that after posting to well over 820
newsgroups on google and my ISP newsgroup server over a period of 4
1/2 months ,Ive raked in $54280 . Mucho dinero baby!!!! Peace 
Drew Dallas - TX