This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]