Re: RFA: Changes to allow extensions to operator set

[Paul Hilfinger <hilfingr at gnat dot 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);

Let me make clear that we do have an existence proof that the changes
I submitted suffice, since we have used them (in patches still to
come) to extend the operator set with the extra Ada operators WITHOUT
extensions to expression.h, expprint.c, etc.  So if something is
missing, it can't be all that much.

> I was thinking more of

> struct operator
> {
>    const char *name;
>    void (*length) (struct expression *exp, struct operator *op, ?others?);
>    int (*eval) (...);
> ...
> };

> struct exp_descriptor
> {
>    int num_oper;
>    const struct operator *op; // is **op easier?
> ...

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,

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

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.

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>
         }
      }

   and of writing (B) LOTS of little functions of the form 

      <type> <func_X> (<args>) {
         <prologue>
         <X code>
      }

   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.

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.

Paul