[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [Dltk-dev] AST Discussion
|
That is the intent, hopefully it's possible. Do you use AST
now?
Thanks
Mark
Is the intent to generalize the AST structure enough to handle a
'language' such as Antlr?
Formally, an Antlr module is composed
of a grammar statement, globally scoped attributes, rules, and rule scoped
attributes. While not exact, in general an attribute can be treated as
an _expression_ and a rule as a statement. The requirements for rewriting
(refactoring?) and formatting will be different from classical expressions and
statements, but hopefully within the scope of the new DLTK abstractions.
Happy to help flush out the
requirements.
Best,
Gerald
At 04:10 PM 4/22/2008,
Mark Howe wrote:
Content-Language:
en-US
Content-Type:
multipart/alternative;
boundary="_000_6355D410F100AC49AF5FB137855762B03636E307cgmb01codegearn_"
Andrey, Andrei and I have had some discussion about the need for a
rewriter for DLTK. The time frame is probably after the release of 1.0 this
summer. However, prior to 1.0 and starting the rewriter we should
discuss changes we may want to make the
AST.
My reasons for suggesting changes to the AST
are:
We should avoid having to work in multiple
AST's on DLTK. With a careful design we should be able to the use the
generic AST for the rewriter and formatting. This is important to avoid
duplication of work among different languages. That won't preclude languages
from using a dedicated AST.
I have some
suggestions to kick start the discussion.
Generalize the ASTNode hierachy
Generalize
the ASTNode hierarchy so it better fits all dynamic languages. Various
languages have different notions of what an '_expression_' and a 'statement'
are. I suggest removing _expression_ and Statement from the ASTNode hierarchy
(i.e. flattening the hierchy). Instead have a property on ASTNode which
returns whether it is a statement or an _expression_. For instance a field
declaration is an _expression_ in Ruby (in fact a method declaration is an
_expression_, although it returns a null) but is currently a Statement ->
Declaration -> FieldDeclaration.
Modify the
ASTVisitor to support the flattened hierarchy, currently it
has
visit(_expression_ ..) visit(Statement..)
visit(MethodDeclaration... visit(ModuleDeclaration and
visit(TypeDeclaration...
change to something
like
visitExpression(ASTNode..
visitStatement(ASTNode etc
and each node would
have to call the appropriate visit method. AST's would probably have to be
created from factories so they can be configured for each language (ie
whether an type of node is a statement or _expression_).
Comments, other suggestions?
Mark
_______________________________________________
dltk-dev
mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev