Re: GDB and scripting languages - which

[Jim Blandy <jimb at codesourcery dot com>]

Eli Zaretskii <eliz@gnu.org> writes:
>> When I search the manual at http://www.lua.org/manual/5.1/, I don't
>> see any references to 'fallbacks'.  The Lua HISTORY file mentions
>> them, but they seem to be an operator overloading mechanism, not an
>> exception-handling mechanism.  Where can I find documentation on
>> these?
>
> Here:
>
>      http://www.lua.org/spe.html
>
> I don't know why this feature isn't mentioned in the current manual,
> maybe it was renamed.

The 'fallbacks' described in that paper aren't exceptions; they're a
mechanism for customizing the built-in operations of Lua, to adapt it
to new applications.

I'm using the term "exception" as it's used in ML, Scheme, C++, Java,
Python, Ruby, PHP, and probably others.  In fact, in the introduction,
after explaining that Lua is an extension language, they say:

    * extension languages are not for writing large pieces of
      software, with hundreds of thousands lines. Therefore,
      mechanisms for supporting programming-in-the large, like static
      type checking, information hiding, and exception handling, are
      not essential

> Python is a full-fledged programming language, not a language created
> for extending other programs.  Do you really think we need networking,
> graphics, and GUI in GDB scripts?  That sounds like an awful overhead.

As others have said, those are examples of the kind of facilities that
are available off-the-shelf to Python users; but as loadable modules,
they wouldn't be present in a Python-extended GDB unless a script
author did use them.

I think the quality of the body of libraries available for use
off-the-shelf with an extension language is an important measure.  For
example, who would have thought XML would matter to a debugger until
Daniel started using it to describe target registers?  And at CSL
we've got other stuff in the pipeline that would have been a pain
without XML.

In the broadest terms, debugging is about watching your programs run.
There are so many possible things people might want to do with that.
To address the three things I mentioned:
- Some kind of remote monitoring would need network support.
- Debugging performance problems would benefit from graphing.
- GUI facilities could broaden the audience of almost anything.

The lesson of GNU Emacs is that you just don't know what people are
going to do with something.  People were shocked to see news and mail
readers, development environments, symbolic calculators, and the like
implemented in Emacs.

Choosing an extension language for GDB with a rich set of libraries
would be a hugely wonderful thing.

> As for familiarity with it, the GDB scripting language we have now is
> even less widespread than Lua.

Definitely true.  Lua would be an improvement over what we have now.
But is it the best choice we could make?