[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[Dltk-dev] AST Discussion
|
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