[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [Dltk-dev] AST Discussion
|
Great.
My current use of the existing DLTK structures is somewhat limited,
coercing rules and attributes both as MethodDeclarations and the grammar
statement as a TypeDeclaration.
Thanks,
Gerald
At 11:39 AM 4/28/2008, Mark Howe wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_6355D410F100AC49AF5FB137855762B03636EB06cgmb01codegearn_"
That is the intent,
hopefully it's possible. Do you use AST now?
Thanks
Mark
- From: dltk-dev-bounces@xxxxxxxxxxx
[
mailto:dltk-dev-bounces@xxxxxxxxxxx] On Behalf Of Gerald
Rosenberg
- Sent: Tuesday, April 22, 2008 5:24 PM
- To: DLTK Developer Discussions
- Subject: Re: [Dltk-dev] AST Discussion
- 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
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev