Re: GDB and scripting languages - which

[Jim Blandy <jimb at codesourcery dot com>]

Robert Dewar <dewar@adacore.com> writes:
> Daniel Jacobowitz wrote:
>
>> I don't think we entirely know how we're going to use this yet.  I
>> have no plans to move C parts to a scripting language - I think that
>> the scripting language should be optional, at least for one release,
>> until we've seen how useful it is.  What happens after that is harder
>> to say.
>
> Seems reasonable to me. In the long run, we may end up implementing
> new features in GDB in the scripting language if that is more
> convenient, so it may end up not being just a user feature.

Incremental changes are the way to go; I don't see that reimplementing
any part of GDB needs to be part of the original plan.

That said: my long-term test of whether an extension language's
integration has been done right is that you *prefer* to implement new
features in the extension language over C whenever possible, just
because it's so much easier and cleaner, and because it doesn't carry
significant disadvantages for users.  In GNU Emacs that's definitely
the case: if you don't need to muck about with redisplay internals or
process control or any of the other essentials, it's obvious that you
do it in Lisp.

That condition holds when the fundamental facilities of the
application (in Emacs: buffers, strings, windows; in GDB: lexical
blocks, source code locations, types, variables, values, frames,
threads) are well-exported enough that you *can* get the job done, and
that the extension language bindings are clean enough that it's
*easier* to get the job done.

The folks doing the first Python Subversion bindings were surprised to
find that simply exporting the C functions to Python in a direct way
produced an interface that just didn't feel right in Python: you were
always worried about managing storage and so on.  Good extension
language bindings preserve the scripting language's common idioms.
(For example: if you're managing reference counts in your scripts,
something is wrong.  If buggy scripts segfault, something is wrong.)