Re: RFA: Changes to allow extensions to operator set

[Andrew Cagney <ac131313 at redhat dot com>]

> +/* Information needed to print and prefixify expressions for a given
> +   language.  */
> +
> +struct exp_descriptor
> +  {
> +    /* Print subexpression */
> +    void (*print_subexp) (struct expression *, int *, struct ui_file *,
> +			  enum precedence);
> +
> +    /* Returns number of exp_elements needed to represent an operator and
> +       the number of subexpressions it takes. */
> +    void (*operator_length) (struct expression*, int, int*, int *);
> +
> +    /* Name of this operator for dumping purposes. */
> +    char *(*op_name) (enum exp_opcode);
> +
> +    /* Dump the rest of this (prefix) expression after the operator
> +       itself has been printed.  See dump_subexp_body_standard in
> +       (expprint.c). */
> +    int (*dump_subexp_body) (struct expression *, struct ui_file *, int);
> +  };

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

I was thinking more of

struct operator
{
  const char *name;
  void (*length) (struct expression *exp, struct operator *op, ?others?);
  int (*eval) (...);
  ?others?
  int opcode; // for backward compatibility
};

struct exp_descriptor
{
  int num_oper;
  const struct operator *op; // is **op easier?
  dump_...;
  print_...;
}

which is a step beyond what you posted.   It should completly eliminate 
the need to add to that OP enum list (and eliminate the enum).

To create backward compatibility, the default table would just have all 
its length() and eval() members pointing at the default_* methods you 
posted (they could pull the "enum exp_opcode" ->opcode).  Ada would have 
a larger table.

Does this work?

> One explanatory comment as to technique: I bundled up a related set of
> function pointers into a new type (struct exp_descriptor) and put a 
> pointer to the structure into the language_defn vectors (i.e., as
> opposed to just adding the four functions contained in it to the
> language_defn vector).  I thought it looked neater, but more to the
> point, it avoided some awkward dependency issues.

Yes, definitly.  Like the strategy.

Andrew