RFA: Ada-related patches, part I

[Andrew Cagney]

> Andrew,
> 
> 
>> You don't appear to have a personal assignment for GDB on file. 
>> Assuming this is being done as an employee of Act, can you please use 
>> your act e-mail address in your ChangLogs.
> 
> 
> Sure, if that will simplify things.  For the record, however, 
> otisco.mckusick.com is the property of Ada Core Technologies.
> 
> 
>> > 	* defs.h (enum language): Add language_ada.
> 
>> 
>> This is ok.
>> 
>> However, this change shouldn't be necessary.  The language code should 
>> be sufficiently modula as to not need this.  Can you/act at least 
>> investigate what would be needed to finish this?
> 
> 
> Umm.  But I notice quite a few tests scattered around the current
> sources having the form ``if (suchandsuch == language_cplus...).''  In
> particular, there are uses in such routines as symbol_natural_name
> that are going to have to be extended for Ada. Perhaps, then, I am a
> bit unclear what you intend here.  

(insert std disclaimer `ignoring c++ ...')

> Are you simply saying that if I find a place in common (i.e., non ada-
> *) files that requires different treatment for Ada than for another
> language, I should introduce a new entry into the language_defn
> structure to handle it object-orientedly rather than performing
> specific ``... == language_ada'' tests?  I'm certainly all for that.

Yes.  Before adding another case to a switch, see of the code can be 
pushed into the language vector.

> Yes, I considered doing that, just as someone (you, as I recall) previously
> asked for OP_ADA_ATTRIBUTE.  However, these operators make sense
> generically; it's just that only Ada uses them at the moment.  
> How's about if I change the comments instead to remove all 
> traces of Ada (see below)?  Your choice.

Which ever.  The re-worded version is much better.

>> (mind you, again, this shouldn't be needed.  Instead these operators 
>> should be objects that language specific modules can just add).
> 
> 
> I think I agree again, and normally would have done just this as a matter
> of course, except that parse.c is not set up to be extensible in this
> way.  The functions prefixify_subexp and length_of_subexp both need to
> know about these opcodes, as things now stand.  Of course, if you are
> asking me to reorganize parse.c and to revise expression.h so as to
> make the operator set open-ended, just say the word.

Wow! is there duplication or what.  Would adding a new operator 
`generic' that, in the expression array, added:
	OP_GENERIC (better name?)
	(operator *) op
	... op->length(exp) elements ...
work?  Something similar for the expression evaluator.

What about op_print?  I guess operator ends up containing similar 
information.

Andrew