Re: RFA: Changes to allow extensions to operator set

[Andrew Cagney <ac131313@redhat.com>]

>> [Where] is a method to handle operator evaluation missing?  Otherwize won't 
>>  the jumbo switch in evaluate_subexp_standard still need to be modified 
>> as languages add additional operators.
> 
> 
> Not so.  The language vector already contains
> 
>     /* Evaluate an expression. */
>     struct value *(*evaluate_exp) (struct type *, struct expression *,
> 				   int *, enum noside);

Ah.  Is ada doing anything special with that - something that will bite 
later?  Looking at the existing languages - they appear to simply be 
overriding select operators but nothing more.

> In short, you want to object orient these suckers.  Well as a matter
> of fact, I actually implemented something along these lines in an earlier
> iteration. It certainly can be made to work.  However,

Yes.

> 1. To do it consistently requires a much more extensive and somewhat
>    tedious change to the existing machinery (which works well enough)
>    giving me even more opportunities to overlook something ("overlook" 
>    == "screw up").

True.  Need to look for baby steps.

> 2. For example, to really do it up brown you'd want to modify all the
>    .y files so that instead of emitting the integer codes directly, as they
>    do now, there'd be operator-specific emission routines for parsing, so
>    that, e.g., sequences like
> 
>         write_exp_elt_opcode (OP_FUNCALL);
> 	write_exp_elt_longcst ((LONGEST) end_arglist ());
> 	write_exp_elt_opcode (OP_FUNCALL); }
> 
>    became
> 
>         OP_FUNCALL->write_exp_longest ((LONGEST) end_arglist ());
> 
>    or some such thing.

Yes, eventually.  In an as yet un-scheduled future round.

> 3. Personally, I find that this is one of those gray cases where the OOP 
>    style gains little in clarity.  That is, we have choice of writing (A) an
>    enumeration type and a few big functions of the form
> 
>       <type> <func> (<args>) {
>          <prologue>
>          switch (<op>) {
>          case A:
> 	   <A code>
>          case B:
> 	   <B code>
>          }
>       }

This, I think, is easier short term.

>    and of writing (B) LOTS of little functions of the form 
> 
>       <type> <func_X> (<args>) {
>          <prologue>
>          <X code>
>       }

This, I think, is easier long term - it's clear exactly which methods 
need to be implemented to make the new object functional - no chasing 
after all those switch statements to figure out if/where each needs to 
be changed.

It took me some time to understand why the OO style really was better 
and how come Java omiting enum's was a good thing.

>    plus a big dispatch vector (of struct operators, in your case) naming them.
>    Perhaps I am overinterpreting your suggestion, but I see a lot of effort
>    for little gain in clarity (maybe <0) in going from the current style (A) 
>    to style (B). In fact, for these reasons, I went so far as to tear up my
>    original, more bject-oriented version of this extension mechanism and
>    go back to the mechanism I submitted, as a simpler and more conservative
>    solution.

sed would quickly create the initial table.

> Now if and when David Carlton gets his way and we eventually re-do GDB
> in C++, it might be time to revisit this decision, since C++ would
> remove the tedious table building and welter of names.

Not if, when.  GDB's beeing re-done OO regardless of the C++ schedule.

Can you please move evaluate_exp to the new expresion descriptor (is 
anything else missing?); modify:

> +    OP_OBJC_NSSTRING,
> +
> +     /* First extension operator.  Individual language modules define
> +        extra operators they need as constants with values 
> +        OP_LANGUAGE_SPECIFIC0 + k, for k >= 0, using a separate 
> +        enumerated type definition:
> +           enum foo_extension_operator {
> +             BINOP_MOGRIFY = OP_EXTENDED0,
> + 	     BINOP_FROB,
> + 	     ...
> +           };      */
> +      OP_EXTENDED0,
> +  
> +     /* Last possible extension operator.  Defined simply to specify a
> +        minimum range for the representation. */
> +     OP_EXTENDED_LAST = 0xff

to provide a an explicit and finite number of extended operators 
OP_EXTENDED_0, OP_EXTENDED_1, ... (I'm assuming Ada will contain enum { 
OP_ADA_... = OP_EXTENDED_0, ... }); add a note that this is an interum 
and it will go away.

Andrew