Re: [Gnome-devtools] Re: Parsing/Language Analysis

[Mark <jamess1 wwnet com>]

Thomas Mailund wrote:
> 
> >>>>> "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.

True.

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

A Dia type program (UML) that works with code would be really cool.
Since two views could share the same source, modifications in the
diagram would change things in the editor, and vice versa this would be
really cool.

> It will be damn hard to get right in the first go, though, but
> evolution of the design should help us there.

Yeah, the whole evolution designing/programming style has worked for me.
I almost never get anything right the first time.
 

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

I agree, but I think we should design the data structures so is easy to
add in later.

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

I think we should have this in there, however I think it would be better
to not base the Language Kernel from tktext since the structure of
tktext is geared toward the display of the text. I'm working on a design
for the Abstract Syntax Tree in Dia, I should have something today or
tomorrow that everyone can comment on. 

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

I think that is the way to do it.

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

Sounds good.

Mark