Hello,

As I said before, the goal of this exercise is to avoid having to play
with the current language in order to do parsing operations in a language
that may not be the current language.

The approach I'm taking to this is that functions that require a
language-specific operation to be done should either:
  - know which language should be used (for instance, an Ada
    exception catchpoint location should be parsed using the Ada
    language)
  - Or: Be passed the language to use as a parameter. This is by
    far the most common case.

At the end of the exercise, the only functions that shoudl be using
the current_language are the function that implement GDB commands.

I've started working on this, and although it's far from being done,
the changes are touching a lot of files. I'm doing the transition
piece-meal, by starting from the expression-parsing routines, and
will work my way up until current_language is only used in "command"
functions.

More precisely, the algorithm used is:

  - Modify the profile of some routines to add a language as a param.

  - Modify the body of these routines to use that language instead
    of the current_language

  - Update the callers of this routine as follow:

      1. If the caller implements a GDB command, then we know that
         the user means that we should be using the current language
         to evaluate his command.

         If the function is only called by "command" functions, then
         I may elect to use "current_language". Adding an extra
         language parameter to that function would be cleaner, but
         on the other hand wouldn't change anything. Not adding it
         reduces the size of the patch.

      2. Otherwise, If we have the language handy, then use that language
         (eg: if the language is a parameter, or if we're given
         a breakpoint as a parameter, for instance)

      3. If the language is not handily available *yet*, then
         use a temporary function called "curr_language ()" that
         returns the current_language.

         In essence, this is like updating the call to use current_language
         except that I'm marking this specific instance so that I can
         easily find again later which uses of current_language I have
         introduced but still need to be removed.

         Note that, when I post the final patches for review,
         curr_language will be removed, and replaced with plain
         old current_language.  This is only used by me as a helper.

At each iteration, I look for some instances of "curr_language",
choose a routine that I want to adjust, and then apply the algorithm
above.

I'm done when there are no longer any curr_language calls :).

Although the changes are rather mechanical, they are fairly extensive
and touch a lot of files. I would really apprieciate some feedback
on the patches attached to this email. This is only a preview of the
entire work which I hope to complete soon.

The patches do:

  - 01-parse_expr.diff:
        Update the parse_expression routines, update the callers.

  - 02-breakpoint.c.diff:
        Transition breakpoint.c. Update all the callers of the functions
        that were adjusted.

  - 03-parse_and_eval_address.diff:
        Update parse_and_eval_address. Update all callers.

I have a bunch of other functions in eval.c that I can transition
as separate patches, so the patches should be reasonably small.
I might bunch them together and that would make one large patch
instead of a collection of small ones, but that would be slightly
simpler for me, because it reduces the number of patches (which may
be large by the time I'm done).

So? Does this look OK for everyone?

Thanks,
-- 
Joel