Re: RFA: Changes to allow extensions to operator set

Paul Hilfinger
2003-09-13T08:58:45Z

Andrew,

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

Nope; it overrides some stuff, and (of course), handles the new operators
it defines.

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

So I guess I don't have to ask how you feel about C# putting them back
in (:->).

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

Yes, and none too soon in general. It's just that for this particular
application --- large sets of operator objects with a fairly small set
of virtual operations in the interface --- I've always found the gains
achieved by the OO formulation to be just a tad disappointing. I find
moreover that to make things readably concise in C or C++, I generally
end up resorting to macros, a separate pre-processing step, or a
specialized implementation language for dealing with expression trees.
The GDB community appears to have an almost superstitious aversion to
macros which I've never entirely understood (probably because I
instinctively write only beautifully clear macro definitions myself
;->). Pre-processing tends to confuse debuggers, and specialized
implementation languages are generally not widely implemented.

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

Sure; sounds sensible.

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

OK.

Paul