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

Daniel Jacobowitz
2008-06-08T18:21:50Z

On Thu, May 29, 2008 at 02:29:32PM -0600, Tom Tromey wrote:
> 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.

This sounds good to me.

> * 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 think this is really necessary. It's not like the user would
be up a creek if they had an arbitrary character that interfered with
the lexer.

Except we do need to define what the arguments to specified functions
are, and I want a clear answer on that point before anything goes in.
They could be Python syntax, or some other well-defined syntax which
happens to be similar to Python. Would GDB convenience variables
work? As values or as textual substitution?

As long as we pick something and document it, I think the choice of
what to pick is not too significant.

> * 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?

Yes, but this is always an issue defining new predefined convenience
variables since they share a namespace with user variables.

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

Making them complete on a string seems too awkward when writing such
things. At function-writing time it would be easier (but less
flexible) to specify a list of arguments and have GDB handle the
breaking up into words... I know we discussed this before but I can't
remember the details now.

--
Daniel Jacobowitz
CodeSourcery