Re: GDB and scripting languages - which

[Eli Zaretskii <eliz@gnu.org>]

> Cc: gdb@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Wed, 14 Feb 2007 11:45:07 -0800
> 
> 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.

Maybe I misunderstand what that means.  Are you looking for `pcall'
(http://www.lua.org/manual/5.1/manual.html#pdf-pcall)?

> 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.

Maybe we should have a more clear idea of what is the scope and
purpose of using a scripting language in GDB.  I don't think it was
ever stated in this whole discussion, so it's quite possible different
people have different ideas about that.

You mention Emacs: are we really going to base our model on Emacs?
Most of Emacs is actually implemented in Lisp, so much so that Lisp
can no longer be seen in Emacs as just an extension language.  The
only parts of Emacs that are not in Lisp are the Lisp interpreter and
the minimal interface to the OS: display, file I/O, memory, etc.  If
the OS could talk Lisp, the C parts of Emacs could be simply thrown
away.

Is this what we intend to do in GDB?  For example, are we going to
rewrite the GDB application level in the scripting language?  Will we
begin accepting general-purpose GDB features that are written entirely
in the scripting language?  If that's the intent, then I agree that an
extension language such as Lua is not going to be good enough.

My impression was that we want a scripting language to do what we do
with it today: prepare canned sequences of commands for batch-style
execution, or defining customized commands that are too specialized to
be included in the upstream distribution.  I thought the bulk of GDB
will remain to be in C, as it is today.  Was I mistaken?