Re: Function syntax

[Tom Tromey <tromey@redhat.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

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

Daniel> This sounds good to me.

Good :)  I actually went ahead and implemented this a little while
back.

Daniel> Except we do need to define what the arguments to specified functions
Daniel> are, and I want a clear answer on that point before anything goes in.

Yes, I totally agree.  IMO this is much more important than the
various implementation details -- those can be changed much more
easily than user-facing behavior.

Daniel> They could be Python syntax, or some other well-defined syntax which
Daniel> happens to be similar to Python.  Would GDB convenience variables
Daniel> work?  As values or as textual substitution?

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

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

The way this works right now is that the first word is stripped from
the text between the parens.  This is the function name and is looked
up in an internal table.  The rest is passed, untranslated, as an
argument.

We talked about doing more parsing here for commands, and I guess by
extension functions.  But I have kind of come around to the other
point of view -- leave the argument as a string and let the callee
deal with it.

One reason I prefer this is that it lets new functions require less
syntax.  For instance, consider my canonical example of a function
that looks to see if the caller's stack frame matches the argument:

    break somewhere if $(caller-is somewhere_else)

If we were dealing with sub-expressions or the like, this would have
to be a string.  That just seems less gdb-ish to me -- though of
course this argument is somewhat weak in that other folks may have a
different idea about the nature of gdb's grammar.

I see your point about convenience variables.  They would not be
automatically interpolated.  On the other hand, nothing prevents a
python function from evalling an argument as a gdb expression.

Another reason I prefer this approach is that in general it is simpler
to write stuff in Python rather than C.  I already plan to ship a
library of useful Python functions with this gdb -- adding more
utility code to handle parsing, completion, etc, is no big deal.

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

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

I think this is an argument to keep the $(fn) syntax -- it would be
nice if these functions had a separate namespace.  One reason in
particular I would like that is that I think we ought to ship a lot of
built-in ones, and it would be nice not to trample all over the user
namespace.

Tom