Ada grammar rules for names too permissive?

Ada grammar rules for names too permissive?

[olivermkellogg]

Hi,

RM section 3.2.2 defines

  subtype_mark ::= (subtype_)name

where (subtype_) is subtype_ rendered in italics, i.e. essentially

  subtype_mark ::= name

This looks overly permissive to me, considering 4.1

  name ::=
     direct_name | explicit_dereference
   | indexed_component | slice
   | selected_component | attribute_reference
   | type_conversion | function_call
   | character_literal | qualified_expression
   | generalized_reference | generalized_indexing
   | target_name

The AARM elaborates in paragraph 4a:

*Ramification*: Note that name includes attribute_reference; thus, S'Base can be used as a subtype_mark.

My question is, why is subtype_mark not defined as follows:

  compound_name ::= identifier { . identifier }

  subtype_mark ::= compound_name [ ' Base ]


Similarly, RM section 10.1.1 defines

  parent_unit_name ::= name

Here my question also applies, why not

  parent_unit_name ::= compound_name


- Oliver
(currently fighting ambiguities in the ANTLR grammar caused by laxity of rules)

Re: Ada grammar rules for names too permissive?

[Randy Brukardt]

Ada semantic rules use the syntax rules and vice versa. In this case, one 
does not want to repeat the various rules for interpreting an expanded name 
(which are part of selected_component).

In this particular case, the resolution rule for subtype_mark eliminates any 
nonsense cases.

There's also two practical considerations: one is that with typical grammar 
generators, you usually have to allow more syntax than you want, as 
differentiating between options requires essentially unlimited lookahead. 
(Most grammar generators use a single token lookahead.) In this case, you 
would have a lot of trouble telling between a type conversion and an indexed 
component, if the prefix syntax was different for each.

Secondly, error detection for generated grammars tends to be less 
understandable than hand written error handling. (My understanding is that 
this is a major reason why GNAT uses a hand-written parser.) So allowing too 
much syntactically allows providing better error messages.

For instance, one could easily require "others" to stand alone with your 
grammar. However, if you do that, the error message ends up being something 
like "unexpected |", which is not very helpful.

                              Randy.

<olivermkellogg@gmail.com> wrote in message 
news:30ba8954-a19e-4c95-b350-798b0276db41@googlegroups.com...
> Hi,
>
> RM section 3.2.2 defines
>
>  subtype_mark ::= (subtype_)name
>
> where (subtype_) is subtype_ rendered in italics, i.e. essentially
>
>  subtype_mark ::= name
>
> This looks overly permissive to me, considering 4.1
>
>  name ::=
>     direct_name | explicit_dereference
>   | indexed_component | slice
>   | selected_component | attribute_reference
>   | type_conversion | function_call
>   | character_literal | qualified_expression
>   | generalized_reference | generalized_indexing
>   | target_name
>
> The AARM elaborates in paragraph 4a:
>
> *Ramification*: Note that name includes attribute_reference; thus, S'Base 
> can be used as a subtype_mark.
>
> My question is, why is subtype_mark not defined as follows:
>
>  compound_name ::= identifier { . identifier }
>
>  subtype_mark ::= compound_name [ ' Base ]
>
>
> Similarly, RM section 10.1.1 defines
>
>  parent_unit_name ::= name
>
> Here my question also applies, why not
>
>  parent_unit_name ::= compound_name
>
>
> - Oliver
> (currently fighting ambiguities in the ANTLR grammar caused by laxity of 
> rules) 

Re: Ada grammar rules for names too permissive?

[Dmitry A. Kazakov]

On 2018-12-31 22:45, Randy Brukardt wrote:
> Ada semantic rules use the syntax rules and vice versa. In this case, one
> does not want to repeat the various rules for interpreting an expanded name
> (which are part of selected_component).
> 
> In this particular case, the resolution rule for subtype_mark eliminates any
> nonsense cases.
> 
> There's also two practical considerations: one is that with typical grammar
> generators, you usually have to allow more syntax than you want, as
> differentiating between options requires essentially unlimited lookahead.
> (Most grammar generators use a single token lookahead.) In this case, you
> would have a lot of trouble telling between a type conversion and an indexed
> component, if the prefix syntax was different for each.
> 
> Secondly, error detection for generated grammars tends to be less
> understandable than hand written error handling. (My understanding is that
> this is a major reason why GNAT uses a hand-written parser.) So allowing too
> much syntactically allows providing better error messages.
> 
> For instance, one could easily require "others" to stand alone with your
> grammar. However, if you do that, the error message ends up being something
> like "unexpected |", which is not very helpful.

This discussion repeats each year! (:-()

Maybe it is worth to write somewhere in c.l.a: attention! Ada needs no 
grammar generators! Never push semantic rules into syntax.

The grammar as written is never the one actually used for whatever 
purpose other than explanation or, maybe, validation. An extreme case 
illustrating why, is source code coloring, but applies to compilers just 
same.

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

Re: Ada grammar rules for names too permissive?

[olivermkellogg]

On Monday, December 31, 2018 at 10:45:46 PM UTC+1, Randy Brukardt wrote:
> Ada semantic rules use the syntax rules and vice versa. In this case, one 
> does not want to repeat the various rules for interpreting an expanded name 
> (which are part of selected_component).

Understood. Thanks for explaining.

I still think that when using Annex P as the direct basis for a parser it would make sense to narrow down the name related rules.
Along these lines:
Do you think it would be permissible to "solidify" the italics?

E.g. in the case of subtype_mark, in the implementation grammar there could be an actual rule subtype_name with a much narrower definition.
That would avoid forcing the parser to jump through the unnecessary hoops of the heavy weight rule `name'.

- Oliver

Re: Ada grammar rules for names too permissive?

[Stephen Leake]

On Saturday, December 29, 2018 at 10:20:41 AM UTC-8, oliverm...@gmail.com wrote:
> - Oliver
> (currently fighting ambiguities in the ANTLR grammar caused by laxity of rules)

This is precisely why I use a generalized LR parser for Emacs Ada mode; I don't have to mess with the published grammar. It works very well in practice.

The LRM is written for people to understand (not computers), and the current style is good for that, I think.

Re: Ada grammar rules for names too permissive?

[Stephen Leake]

On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote:
> The grammar as written is never the one actually used for whatever 
> purpose other than explanation or, maybe, validation. An extreme case 
> illustrating why, is source code coloring, 

On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P.

I'm sure there are other examples that illustrate your point.

Re: Ada grammar rules for names too permissive?

[Dmitry A. Kazakov]

On 2019-01-01 20:49, Stephen Leake wrote:
> On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote:
>> The grammar as written is never the one actually used for whatever
>> purpose other than explanation or, maybe, validation. An extreme case
>> illustrating why, is source code coloring,
> 
> On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P.

In which case it should not work with syntactically incorrect programs.

The grammar describing a reasonably good color schema and the grammar 
describing syntactically correct Ada programs must be sufficiently 
different.

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

Re: Ada grammar rules for names too permissive?

[olivermkellogg]

On Tuesday, January 1, 2019 at 9:06:59 PM UTC+1, Stephen Leake wrote:
> > [...]
> 
> This is precisely why I use a generalized LR parser for Emacs Ada mode; I don't have to mess with the published grammar. It works very well in practice.

Hmm... I downloaded org.emacs.ada-mode-6.0.1.tar.bz2, is that what you are talking about?
In there, I see a file ada.wy which seems to be an Ada grammar, is that what you are talking about?

What do you do with 12.3 :

explicit_generic_actual_parameter ::= expression | (variable_)name
| (subprogram_)name | (entry_)name | subtype_mark
| (package_instance_)name

If I leave away the italics I get:

explicit_generic_actual_parameter ::= expression | name
| name | name | subtype_mark
| name

So.. it seems I can answer my own question about solidifying the italics;
that's what should be done, otherwise we get nonsense.

Re: Ada grammar rules for names too permissive?

[Stephen Leake]

On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote:
> On 2019-01-01 20:49, Stephen Leake wrote:
> > On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote:
> >> The grammar as written is never the one actually used for whatever
> >> purpose other than explanation or, maybe, validation. An extreme case
> >> illustrating why, is source code coloring,
> > 
> > On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P.
> 
> In which case it should not work with syntactically incorrect programs.

No, it has error correction to deal with that.

Re: Ada grammar rules for names too permissive?

[Stephen Leake]

On Tuesday, January 1, 2019 at 1:03:34 PM UTC-8, oliverm...@gmail.com wrote:
> On Tuesday, January 1, 2019 at 9:06:59 PM UTC+1, Stephen Leake wrote:
> > > [...]
> > 
> > This is precisely why I use a generalized LR parser for Emacs Ada mode; I don't have to mess with the published grammar. It works very well in practice.
> 
> Hmm... I downloaded org.emacs.ada-mode-6.0.1.tar.bz2, is that what you are 
talking about?

Yes. It's also a GNU ELPA package.

> In there, I see a file ada.wy which seems to be an Ada grammar, is that what you are talking about?

Yes. 

> What do you do with 12.3 :
> 
> explicit_generic_actual_parameter ::= expression | (variable_)name
> | (subprogram_)name | (entry_)name | subtype_mark
> | (package_instance_)name

I eliminated it, along with generic_actual_part, because "name ( generic_actual_part ) " is a subset of "name ( actual_parameter_part )". That's what the comment at "generic_instantiation" is trying to say.

So ada.wy accepts a larger language than LRM Annex P; that's part of the strategy for handling incorrect syntax.

Perhaps "minimal changes" is not a correct description for this kind of change, but the changes I made only allow more choices for each token, they don't change the basic structure of the productions.

> If I leave away the italics I get:
> 
> explicit_generic_actual_parameter ::= expression | name
> | name | name | subtype_mark
> | name
> 
> So.. it seems I can answer my own question about solidifying the italics;
> that's what should be done, otherwise we get nonsense.

It's not nonsense, it's just redundant, and an indication that the legality should be checked by the post-parsing phases. ada.wy deals with such redundancies by including only the minimal set that covers the original.

There are still redundancies (listed in the %conflict declarations); those are handled at runtime by the generalized parser.

Re: Ada grammar rules for names too permissive?

[Dmitry A. Kazakov]

On 2019-01-02 20:21, Stephen Leake wrote:
> On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote:
>> On 2019-01-01 20:49, Stephen Leake wrote:
>>> On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote:
>>>> The grammar as written is never the one actually used for whatever
>>>> purpose other than explanation or, maybe, validation. An extreme case
>>>> illustrating why, is source code coloring,
>>>
>>> On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P.
>>
>> In which case it should not work with syntactically incorrect programs.
> 
> No, it has error correction to deal with that.

Ada grammar contains no correction productions.

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

Re: Ada grammar rules for names too permissive?

[Stephen Leake]

On Wednesday, January 2, 2019 at 12:47:22 PM UTC-8, Dmitry A. Kazakov wrote:
> On 2019-01-02 20:21, Stephen Leake wrote:
> > On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote:
> >> On 2019-01-01 20:49, Stephen Leake wrote:
> >>> On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote:
> >>>> The grammar as written is never the one actually used for whatever
> >>>> purpose other than explanation or, maybe, validation. An extreme case
> >>>> illustrating why, is source code coloring,
> >>>
> >>> On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P.
> >>
> >> In which case it should not work with syntactically incorrect programs.
> > 
> > No, it has error correction to deal with that.
> 
> Ada grammar contains no correction productions.

True for LRM Annex P, and also for Emacs ada.wy, but irrelevant. For LR parsers, there are error correction algorithms that do not require modifying the grammar. Emacs ada-mode uses the McKenzie algorithm (1); exploration of the parse table near the error location, combined with the redundancy of the Ada language (especially named blocks).

One of these days I'll have to write a paper on it ...

Meanwhile, it works quite nicely for me, and I'm waiting to hear from more people on how it works for them (a few positive responses so far, no negative).

(1) McKenzie, Bruce J., Yeatman, Corey, and De Vere,
    Lorraine. Error repair in shift reduce parsers. ACM Trans. Prog.
    Lang. Syst., 17(4):672-689, July 1995.
  

Re: Ada grammar rules for names too permissive?

[Jere]

On Thursday, January 3, 2019 at 5:05:34 PM UTC-5, Stephen Leake wrote:
> On Wednesday, January 2, 2019 at 12:47:22 PM UTC-8, Dmitry A. Kazakov wrote:
> > On 2019-01-02 20:21, Stephen Leake wrote:
> > > On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote:
> > >> On 2019-01-01 20:49, Stephen Leake wrote:
> > >>> On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote:
> > >>>> The grammar as written is never the one actually used for whatever
> > >>>> purpose other than explanation or, maybe, validation. An extreme case
> > >>>> illustrating why, is source code coloring,
> > >>>
> > >>> On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P.
> > >>
> > >> In which case it should not work with syntactically incorrect programs.
> > > 
> > > No, it has error correction to deal with that.
> > 
> > Ada grammar contains no correction productions.
> 
> True for LRM Annex P, and also for Emacs ada.wy, but irrelevant. For LR parsers, there are error correction algorithms that do not require modifying the grammar. Emacs ada-mode uses the McKenzie algorithm (1); exploration of the parse table near the error location, combined with the redundancy of the Ada language (especially named blocks).
> 
> One of these days I'll have to write a paper on it ...
> 
> Meanwhile, it works quite nicely for me, and I'm waiting to hear from more people on how it works for them (a few positive responses so far, no negative).
> 
> (1) McKenzie, Bruce J., Yeatman, Corey, and De Vere,
>     Lorraine. Error repair in shift reduce parsers. ACM Trans. Prog.
>     Lang. Syst., 17(4):672-689, July 1995.

Is there a guide on how to manually update the Ada mode part of emacs?  I 
have a slightly older version, but it doesn't list ada mode in emacs
when I go through the normal update procedure.  I can't really update emacs
itself due to IT policies but was hoping to test out the newer Ada mode
fixes at some point.  In the version I have, it has trouble with things
like expression functions (situations where you have "is" but no "begin/end"
blocks).

Re: Ada grammar rules for names too permissive?

[Randy Brukardt]

<olivermkellogg@gmail.com> wrote in message 
news:8f1d7dde-b982-42ff-93d6-5d19dac92f3b@googlegroups.com...
> On Monday, December 31, 2018 at 10:45:46 PM UTC+1, Randy Brukardt wrote:
>> Ada semantic rules use the syntax rules and vice versa. In this case, one
>> does not want to repeat the various rules for interpreting an expanded 
>> name
>> (which are part of selected_component).
>
> Understood. Thanks for explaining.
>
> I still think that when using Annex P as the direct basis for a parser it 
> would make sense to narrow down the name related rules.
> Along these lines:
> Do you think it would be permissible to "solidify" the italics?
>
> E.g. in the case of subtype_mark, in the implementation grammar there 
> could be an actual rule subtype_name with a much narrower definition.
> That would avoid forcing the parser to jump through the unnecessary hoops 
> of the heavy weight rule `name'.

So long as you aren't representing that the grammar is exactly that of the 
RM, you can make any changes to it that you want. You pretty much have to do 
that in any purely syntactic grammar (indexed_component and type_conversion 
are ambiguous, for instance). As Dmitry said, the grammar of Annex P isn't 
directly useful for much of anything (other than human reading). [Yes, we 
know that, we inherited it from Ada 83 and haven't wanted to change it in 
part because things like ASIS are heavily dependent on the Annex P grammar.]

                          Randy.

Re: Ada grammar rules for names too permissive?

[olivermkellogg]

On Tuesday, January 1, 2019 at 9:44:17 AM UTC+1, Dmitry A. Kazakov wrote:
> [...]
>       Never push semantic rules into syntax.

I'm not so sure about that:
A nice feature of ANTLR is that is supports semantic predicates which can be embedded in the grammar.
For example, using sem preds on the basis of symbol tables would permit discerning among indexed_component, type_conversion, function_call.

> The grammar as written is never the one actually used for whatever 
> purpose other than explanation or, maybe, validation.

The interesting question IMO is:
What are the necessary transformations for going from Annex P BNF plus informal description of semantic rules to the actual implementation grammar.

- Oliver

Re: Ada grammar rules for names too permissive?

[Dmitry A. Kazakov]

On 2019-01-03 22:45, Stephen Leake wrote:
> On Wednesday, January 2, 2019 at 12:47:22 PM UTC-8, Dmitry A. Kazakov wrote:
>> On 2019-01-02 20:21, Stephen Leake wrote:
>>> On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote:
>>>> On 2019-01-01 20:49, Stephen Leake wrote:
>>>>> On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote:
>>>>>> The grammar as written is never the one actually used for whatever
>>>>>> purpose other than explanation or, maybe, validation. An extreme case
>>>>>> illustrating why, is source code coloring,
>>>>>
>>>>> On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P.
>>>>
>>>> In which case it should not work with syntactically incorrect programs.
>>>
>>> No, it has error correction to deal with that.
>>
>> Ada grammar contains no correction productions.
> 
> True for LRM Annex P, and also for Emacs ada.wy, but irrelevant. For LR parsers, there are error correction algorithms that do not require modifying the grammar. Emacs ada-mode uses the McKenzie algorithm (1); exploration of the parse table near the error location, combined with the redundancy of the Ada language (especially named blocks).

Regardless how good or bad that works, it is not the grammar that is 
actually in use.

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

Re: Ada grammar rules for names too permissive?

[Dmitry A. Kazakov]

On 2019-01-03 23:39, olivermkellogg@gmail.com wrote:
> On Tuesday, January 1, 2019 at 9:44:17 AM UTC+1, Dmitry A. Kazakov wrote:
>> [...]
>>        Never push semantic rules into syntax.
> 
> I'm not so sure about that:
> A nice feature of ANTLR is that is supports semantic predicates which can be embedded in the grammar.
> For example, using sem preds on the basis of symbol tables would permit discerning among indexed_component, type_conversion, function_call.

In presence of overloading, really? Anyway, I see no use in such a 
distinction in general.

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

Re: Ada grammar rules for names too permissive?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:q0n77h$2e4$1@gioia.aioe.org...
> On 2019-01-03 23:39, olivermkellogg@gmail.com wrote:
>> On Tuesday, January 1, 2019 at 9:44:17 AM UTC+1, Dmitry A. Kazakov wrote:
>>> [...]
>>>        Never push semantic rules into syntax.
>>
>> I'm not so sure about that:
>> A nice feature of ANTLR is that is supports semantic predicates which can 
>> be embedded in the grammar.
>> For example, using sem preds on the basis of symbol tables would permit 
>> discerning among indexed_component, type_conversion, function_call.
>
> In presence of overloading, really? Anyway, I see no use in such a 
> distinction in general.

Right. That might work in other languages, but in Ada that is a very complex 
algorithm. You'd think that the lack of object overloading would help, and 
it does, but not enough, since you can have a function that returns an array 
that is then indexed, as opposed to a function that returns an 
access-to-function. They both could look like:
     F (1) (2)

And you don't want the grammar to be too smart, simply because hand-written 
error messages are almost always better than automatically generated ones, 
once you get past the trivial (missing punctuation).

                          Randy.

Re: Ada grammar rules for names too permissive?

[Stephen Leake]

On Thursday, January 3, 2019 at 2:34:41 PM UTC-8, Jere wrote:
> 
> Is there a guide on how to manually update the Ada mode part of emacs?  

The original Emacs Ada mode is a "built-in package"; it is included in the installation tarball.

The latest version is a "GNU ELPA package"; it can be installed in any Emacs version >= 25.0.

To install, execute M-x list-packages, search for "ada-mode", type 'i' for Install, 'x' for execute. Wait for Emacs to contact the ELPA server and install the package. Then restart Emacs (to ensure everything got done correctly).

> I 
> have a slightly older version, but it doesn't list ada mode in emacs
> when I go through the normal update procedure.  

What do you mean by "the normal update procedure"? If that means 'list-packages' as I said above, then something (presumably your site administrator) has redirected the default package archive; `package-archives' must include ("gnu" . "https://elpa.gnu.org/packages/"). In that case, ask the site admin to include ada-mode in the local archive. 

If that fails, you'll have to install from source. The simplest approach to that is to check out the git worktree for elpa.

Re: Ada grammar rules for names too permissive?

[Stephen Leake]

On Thursday, January 3, 2019 at 2:39:12 PM UTC-8, oliverm...@gmail.com wrote:
> A nice feature of ANTLR is that is supports semantic predicates which can be embedded in the grammar.
> For example, using sem preds on the basis of symbol tables would permit discerning among indexed_component, type_conversion, function_call.

That could be useful for colorization; Emacs Ada-mode takes a simplistic approach to coloring identifiers.

libadalang takes a different approach; it does some semantic analysis after parsing, including name resolution.

> The interesting question IMO is:
> What are the necessary transformations for going from Annex P BNF plus informal description of semantic rules to the actual implementation grammar.

That totally depends on the purpose of the implementation. A compiler has very different requirements from an IDE engine.

-- Stephe

Re: Ada grammar rules for names too permissive?

[J-P. Rosen]

Le 05/01/2019 à 19:46, Stephen Leake a écrit :
> The latest version is a "GNU ELPA package"; it can be installed in
> any Emacs version >= 25.0.
> 
> To install, execute M-x list-packages, search for "ada-mode", type
> 'i' for Install, 'x' for execute. Wait for Emacs to contact the ELPA
> server and install the package. Then restart Emacs (to ensure
> everything got done correctly).
> 
Just did that with Emacs 26.1/Windows 10, and it fails with:
package--check-signature-content: Failed to verify signature:
"ada-mode-6.0.1.tar.sig"

What's wrong?

-- 
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: Ada grammar rules for names too permissive?

[Stephen Leake]

On Monday, January 7, 2019 at 3:11:45 AM UTC-8, J-P. Rosen wrote:
> Le 05/01/2019 à 19:46, Stephen Leake a écrit :
> > The latest version is a "GNU ELPA package"; it can be installed in
> > any Emacs version >= 25.0.
> > 
> > To install, execute M-x list-packages, search for "ada-mode", type
> > 'i' for Install, 'x' for execute. Wait for Emacs to contact the ELPA
> > server and install the package. Then restart Emacs (to ensure
> > everything got done correctly).
> > 
> Just did that with Emacs 26.1/Windows 10, and it fails with:
> package--check-signature-content: Failed to verify signature:
> "ada-mode-6.0.1.tar.sig"
> 
> What's wrong?
> 

There must have been a glitch downloading the files - I just tried and it worked for me.

So try again. I'm not sure how well the packages tool cleans up after this error - you may have to manually delete files in ~/.emacs.d/elpa

Note that to get the error-correcting parser, you have to manually compile Ada code - see ada-mode.info.

-- Stephe