Re: [CEDET-devel] Parsing method bodies

[David P. <dav...@wa...>]

Hi Eric & Paul,

Here are my thoughts about your different messages in this thread:

[...]
> This assumes that it is possible to use the wisent-java.wy grammar
> that David created as a starting point for creating a grammar whose
> productions build the list of UDTs to import, i.e., that you can
> put arbitrary Lisp code into the grammar's productions to specify
> actions to take when the parser identifies a grammatical construct.
> Is this possible with wisent, David?
[...]

Of course yes!  Wisent is a "strict" port of bison 1.3 code to Elisp,
it can be used independently of semantic, and allows you to use any
kind of Elisp code in semantic actions.

[...]
> The advantage of the parse-tree-visitor approach is that it provides
> true language independence, e.g., you don't have to make compromises
> in terminology or content.
[...]
> The language grammar determines the names of the abstract visitor classes
> generated from it, e.g., a C grammar would result in an
> include-visitor and a Java grammar in an import-visitor.
[...]

Perhaps I am wrong, but it looks to me that the language independence
is only at the "visitor" pattern level.  Each client will have to
define its own visitors to benefit of parse tree data.

The semantic approach is to provide an abstract view of generic
programming language concepts like data type, function, variable,
scope, etc..

Based on those abstract concepts, semantic provides a rich set of high
level APIs, so you can develop applications that will work for mostly
all semantic supported languages, without doing anything special.

IMHO, the "visitor" pattern seems more a OO replacement of the
semantic-tag API.  Or am I missing something?

[...]
> Anyway, I don't know where your parser style fits with those goals.
> It might be easier to continue to the use of the existing, and quite
> flexible tagging format David created and create EIEIO objects for
> visiting those tables in a structured way.  This would be similar to
> the existing override methods, with the advantage of storage while
> traversing a parse tree.  I know that is very different from what you
> describe, but it might provide the flexibility you are looking for.

I agree with you Eric.  With the new tagging format, it is easy to
create new classes of tags, and give tags new attributes for new
language elements.

The semantic-tag, and semantic-find APIs already exist to "visit" the
tag tree.

An important thing to not forget, is that the tag tree structure maps
the input source structure too and interaction between tags and Emacs
buffer data is automatically handled by semantic back-end mechanisms.

IMO, mostly we have to decide on a representation of language
elements, i.e. which new tag attributes do we need, if we need new
ones?

Very rich discussion ;-)

David