[Gnome-devtools] Re: Parsing/Language Analysis

[Thomas Mailund <mailund mail1 stofanet dk>]

>>>>> "M" == Mark  <jamess1 wwnet com> writes:

 [snip]

 M> And lastly the user applications: gIDE, gtkeditor, ect...

Just some nitpicking.  GtkEditor isn't really an application.  In this
context, the editor widget can be considered a view on the "source
object", namely the source-text.  Other views then could be
UML-diagrams, flow-diagrams, and whatnot.

 M> Since the framework is very general, a large amount of language
 M> based tools can be built around it. Obvious things would be a
 M> editor, class browser, ect. Although other more advanced tools are
 M> possible as well.

Oh yeah!  A model/view/controller architecture where the source is
kept (in some structure such as abstract syntax trees) in one
component, and different tools/components such as
UML/CPN/Work-flow/editors all provide views/controllers would kick
ass.  It will be damn hard to get right in the first go, though, but
evolution of the design should help us there.


 M> Implementation:
 M> -----------------

 M> Following a somewhat strict implementation of the Harmonia
 M> framework, I think the Gtk Object system is well suited to the
 M> task.

 M> Language Kernel: Data: Would most likely be GtkObject derived.
 M> Would contain the document text in the syntax tree.

yup.

 M> Methods: I imagine there would be methods for inserting and
 M> deleting text, as well as getting/setting information at the nodes
 M> of the syntax tree.  Also if versioning was decided to be
 M> supported, there would be methods for undoing operations, or
 M> setting the tree to a particular version.

The Wagner paper[2] handles versioning very well, as far as I can see,
and it seems to work well with the other stuff.  I'm not sure,
however, that we should put this in from the very beginning.
Depending on the amount of work, it makes sense to add it after we
have the basics up and running.  Here, by basics, I refer to
incremental lexing and parsing, and using the trees we get from this
to do something useful, for example hiliting, indenting, and similar.

 M> Algorithms: See [2] for a description of the incremental
 M> algorithms employed.

 M> Signals: Signals would be emitted primarily from changes in the
 M> syntax tree, such as a new node being created, or a node being
 M> deleted, or a node being changed.

If we want multiple views on text it also makes sense to emit signals
whenever a string is changed.  I'm not sure if we want this here, or
we rely on tktext for getting this.

Anyway, we could add all kinds of signals, and let the views decide
which kind of changes they need to be notified of.

 M> Language Modules: These would be implemented using a few different
 M> techniques. First I think some kind of dynamic object system might
 M> be required, for any type of language inheritance.

When we talked about this in the editor, I looked at the BSE object
system <URL:http://beast.gtk.org/>.  It is similar to GtkObjects, but
it allows dynamic loading (and unloading, which is the hard part with
GtkObjects).  We should be able to modify this to our needs.

        /mailund