Re: RFA: Changes to allow extensions to operator set

Andrew Cagney
2003-09-11T18:55:16Z

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