GDB and scripting languages - which

[Daniel Jacobowitz <drow at false dot org>]

First, disclaimer: this particular topic is a classic source of
bikeshedding.  I'd like to avoid a prolonged discussion of scripting
language pros and cons on this list.  So, please, limit on-list
followups to the question of single versus multiple bindings and the
use of guile, OK?  If you want to rant at me about my heretic selection
of languages, feel free, but please don't reply to the list in that
case.

Basically, my question is whether we should support one language or
many, and if only one, which.  The GNU coding standards have this
to say:

  The standard extensibility interpreter for GNU software is GUILE
  (http://www.gnu.org/software/guile/), which implements the language
  Scheme (an especially clean and simple dialect of Lisp). We don't
  reject programs written in other scripting languages such as Perl and
  Python, but using GUILE is very important for the overall consistency
  of the GNU system.

So the obvious thing to do would be to have just one and have it be
guile.  I'm not sure how much consistency that really adds - I could
only find a handful of GNU programs embedding guile.  And it presents
another problem for me: I'm a pretty much incompetent Scheme
programmer.  I'm a lot more inspired to add a scripting language
that I can really use.

Python would be my first choice, today.  Mostly this is because I know
it.  However (comparing to guile only here), my impression is that the
user community and library of supporting modules is much stronger than
guile's.  For instance, while this isn't the most meaningful statistic,
there are eighteen times as many python-related packages in Debian as
guile-related.  A whole lot of those are reusable modules.

The advantage of adding multiple language bindings is that users will
have the choice of whichever is more familiar for them; I know that
various people have locally added guile, python, and perl in the past.
The disadvantage, of course, is the required amount of code
(maintenance, testing).  And if GDB comes with a library of useful
routines to load from user scripts, they'll be different for each
language.  And if programs ship their own handy scripts for developers
of those programs to use, they'll be in an assortment of different
languages.

So the short version is that if I were making the decision, for my own
benefit and independent of the GNU project and GDB's users, I'd add
only Python support.  For GDB's place in the GNU project, we should
probably have guile.  And I feel like the user convenience of a
selection of languages will outweigh the extra work of multiple
language bindings.

Accordingly, I am inclined to use multiple bindings, to include at
least Python and GUILE.  My current design relies on GDB/MI for most
control of GDB; I might put the MI parser on the C side of the
interface to allow MI results to be easily converted to lists / tuples
/ et cetera in each supported language, but other than that it
would be a fairly thin interface on top of MI.

(MI isn't the most convenient interface for scripting - I'm still
trying to figure out how it will interact with GDB's value objects, but
it will probably build on top of varobj to do so.  The symmetry is
nice; what you can do in scripts you ought to be able to do in a
GUI front end to GDB too so any MI extensions useful for one
are likely useful to the other.  However, this is the subject of
a later discussion, not this one.)

I'd really appreciate hearing what others think.

-- 
Daniel Jacobowitz
CodeSourcery