Re: [RFC/RFA] add struct parse_context to all command functions

[Joel Brobecker <brobecker at adacore dot com>]

Har har har, I should be able to be active again soon :-)

> I'd like to start working on adding a struct parse_context again.
> The ultimate goal is to pass this structure as an argument to all
> the "parse..." routines, rather than rely on the current_language
> and input_radix globals.  In addition to being cleaner, it will also
> help fix a bug where the current_language is switched under us while
> trying to do parse an expression.

Going back to this, Tom and I exchanged a couple of emails, and
the discussion lead to an interesting suggestion. The base for the
suggestion is that Tom wonders whether it might be a little excessive
to push this extra argument that might actually only be used by a
subset of the commands. I initially agreed, but then thought about
it some more, and realized that all the command functions receive
the arguments as a string, and thus can potentially parse it.
So, always passing the parsing context wouldn't seem unreasonable
to me either. In any case, the idea that emerged is that we could
provide 2 possible command profiles, dependending on what the specific
needs of the function are. The advantage is that we then only
transition the command functions that need the parse context,
and the transition can be done piecemeal.  The issue is that
we will have to duplicate all the various add_cmd functions for
the new extended profile.

So we have 3 alternatives:

  1. All command functions receive the parse_context structure.
     Do the transition all at once.

  2. All command functions should receive the parse_context structure.
     Do the transition gradually by introducing a set of "old_add_..."
     functions that allow to hook command functions that have the old
     profile.

  3. Only the command functions that needed it would be passed
     the parse_context. Add a second set of add_... routines
     to hook these command functions.

I am 50/50 on (1) and (3). I like (2) a little less. Long term,
I think I prefer (1), but it's more painful in the short term.
I don't mind taking the initial hit, but other's opinion welcome.

Perhaps it's another bikeshed discussion, in which case let me know,
and I'll just decide on my own. It's just that it's such a large change
that I want to make sure I won't screw anyone up.

-- 
Joel