Function syntax (Was: [RFC][patch 1/9] initial Python support)

[Tom Tromey <tromey@redhat.com>]

I think this response should be its own thread.

Daniel> For the general syntax: Should we allow $() to always mean Python, or
Daniel> are there other useful potential scripting interfaces or environment
Daniel> variable access or anything, in which case we want $(python ) or $(P )
Daniel> or $python( )?  There are only so many nice grouping specifiers.  $<>
Daniel> is not so good but we still have $[] and ${}, plus $env().  I don't
Daniel> remember if we discussed this before, but we may have.

Recently I've been thinking that $(...) should not simply eval the
'...' as a python expression.  Instead, I'm leaning more toward a
function registry approach.  I have two reasons for this.

First, pure Python syntax is somewhat clunky for the gdb user.  E.g.,
I used this to make a breakpoint conditional on the calling function:

cond 1 $(gdb.current_frame().get_prev().get_name() == "declspecs_add_type")

That's a lot of "()" for a pretty simple action.
Instead, we could provide little helper functions and get:

cond 1 $(caller-is "declspecs_add_type")

The second reason is that with explicit registration and function
objects (like the existing command objects) we could allow nicer
completion inside the $(...).

We can always provide a function named "python" to eval its argument.

As to some of the other things you mentioned:

* I agree with the lexing point.  I think we could specify some
  standardized quoting and dequote before passing the argument to the
  underlying code.

* I don't want to use $python(...) -- but I was wondering, doesn't
  this already have a meaning if 'python' happens to be a
  function-pointer-valued convenience variable?

* I don't think we should worry about supporting any scripting
  language other than Python.  Stuff like getenv access or reflective
  access to gdb 'set' variables can all be done via the python code.
  Anyway, the explicit-function-registration approach leaves open the
  possibility of built-in functions written in other ways.


I suppose my basic proposal is that all functions be derived from
something like:

class Function:
    # ARG is a string, already de-quoted and whitespace-stripped.
    def invoke(self, arg):
        do something

    def complete(self, text, word):
        complete the argument

This is basically exactly what we do for commands, only in the
Function case we could expect invoke to return a value.

Tom