This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Function syntax (Was: [RFC][patch 1/9] initial Python support)
- From: Daniel Jacobowitz <drow at false dot org>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Thiago Jung Bauermann <bauerman at br dot ibm dot com>, gdb-patches at sourceware dot org
- Date: Sun, 8 Jun 2008 14:21:28 -0400
- Subject: Re: Function syntax (Was: [RFC][patch 1/9] initial Python support)
- References: <m31w3ketw3.fsf_-_@fleche.redhat.com>
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