AST Restructuring

We have been restructuring our ASTs. This page includes a list of the guiding principles.

Possible considerations

  • Better match up / unify LetExpr and other declaration-level constructs. Why is LetExpr done nesting-style, while local mutable variables, and variable bindings in traits, objects, and at component level are not?
  • Juxt.multiJuxt and Juxt.infixJuxt are used during type checking. Restructure them. (After FnRef/OpRef/_RewriteFnRef settle down.)
  • Get rid of _RewriteFnRef. (After the interpreter's rewriter is cleaned up. trunk/ProjectFortress/src/com/sun/fortress/interpreter/rewrite/DesugarerVisitor.java treats FnRef so special.)
  • Merge FnRef and OpRef. Similarly, merge _RewriteFnRefOverloading and _RewriteOpRefOverloading. (After the interpreter's rewriter is cleaned up. trunk/ProjectFortress/src/com/sun/fortress/interpreter/rewrite/DesugarerVisitor.java treats FnRef so special.)
  • Get rid of _Rewrite nodes and replace with "this information is known" in extant AST nodes somehow.
    • Top-level declarations (?)
      • _RewriteFnOverloadDecl
      • _RewriteFunctionalMethodDecl
    • Will die after the closure conversion of object expressions is on-line
      • _RewriteObjectExprDecl
      • _RewriteObjectExpr
      • _RewriteObjectExprRef
  • Include FnExpr as a field of FnDecl and eliminate Applicable. (After the native story is cleaned up. trunk/ProjectFortress/src/com/sun/fortress/interpreter/glue/NativeApp.java muddies the water.)
  • Somehow unify ObjectExpr and ObjectDecl. (After _RewriteObjectExpr is eliminated.)
  • Treat CoercionInvocation as invocation of a special function named "coerce" (After coercion is implemented.)
  • Consider adding interfaces that describe stuff that appears or disappears in different phases? This might make it easier to write and update consistency checks for ASTs. (After the phases settle down.)
  • Use  Scala option types instead of nulls or  PLT option types. (After the work related to Scala code settles down.)

Done (These should remain true.)

General principles

  • Do not make the number of fields unwieldy. This would detract from the conciseness of pattern matching. (Note FnAbsDeclOrDecl and ObjectAbsDeclOrDecl violate this dictum rather egregiously; not obvious if / how to solve this. Perhaps we can at least pull out the fields these share in common in some way.) done in: r3246
  • Remove optional fields. Instead of providing default values to the optional fields, provide static methods with the default values. done in: r3186, r3187, r3189~r3193, r3198~r3200, r3202, r3203, r3210
  • Get rid of superclasses with one subclass (FnDecl etc.) done in: r3077
  • Do not repeat field declarations in subclasses. The common fields between subclasses should appear in the same order. done in: r3092, r3098, r3099
  • As it always has been (except for the syntax abstraction nodes), a concrete node class should not have any subclasses. done in: r3101
  • Eliminate unnecessary interfaces. done in: r3116
  • Use names (including field names) that are not Java reserved words, nor Scala reserved words, nor Fortress reserved words. done in: r3122, r3123
  • Use only unboxed primitive types. done in: r3125

Ambiguous nodes and _Rewrite nodes

  • Add interfaces describing after which compiler phase the nodes are eliminated:
    • AmbiguousMultifixOpExpr done in: r3178
  • Add interfaces describing after which compiler phase the nodes are introduced:
    • _RewriteFnApp done in: r3177
  • Get rid of _Rewrite nodes and replace with "this information is known" in extant AST nodes somehow:
    • _RewriteGenericSingletonType done in: r3144
    • _RewriteGenericArrowType done in: r3145
    • _RewriteObjectRef done in: r3146
    • _RewriteFieldRef done in: r3149
    • _RewriteFnRefOverloading done in r3155
    • _RewriteOpRefOverloading done in r3155

Compilation units

  • Clean up "exports" story (may require syntax cleanup); right now we have export nodes that export a list of APIs, and every component has a list of these export nodes. One of these things shouldn't need a list. Should be able to axe Export node. done in: r3078
  • Get rid of objectExprs and functionalMethodNames fields from Component, replace with appropriate top-level decl nodes. done in: r3112

Declarations

  • LocalVarDecl and VarDecl have different fields, and the former takes LValueBinds while the latter takes LValues. done in: r3082
  • Remove distinctions between declarations in APIs (AbsDecl) and in components (Decl). Instead, use one node for both with an extra field to denote the context. It would be much preferable if we can eliminate the extra field. Visitors over ASTs might be able to keep track of whatever context they need to in order to determine this for themselves. Note we still need abstract declarations for variables (fields) and functions, but this distinction should be minimized. done in: r3093~r3096
  • Consider making Decl a superclass rather than an interface. done in: r3097
  • Consider treating varargs-ness as a parameter modifier, get rid of children of Param/TupleType/TupleExpr. done in: r3105, r3107, r3109, r3111
  • Replace modifiers by a bucket of flags or enum. done in: r3207

Expressions

  • If FlowExpr and DelimitedExpr aren't being used for any purpose, get rid of these abstract supertypes. (Presently only used in parser.) done in: r3079
  • Get rid of AppExpr entirely as it appears to be unused. done in: r3100
  • Add optional op for CaseClause. done in: r3101
  • Consider getting rid of Block and replacing by DoFront (best) or Do (gratuitously complicated). --> Replace DoFront with Block. done in: r3137
  • Unify GeneratedExpr and For (or at least common them up in some fashion, perhaps along with other generator-y things). done in: r3138
  • Merge tight and loose juxt. done in: r3182

Types

  • Unify Domain and TupleType somehow (or at least the varargs bits of them). done in: r3114
  • Merge TupleType and VoidType. done in: r3133
  • For type-level operators (dimensions, nats, booleans, etc), consider just having unary and binary operator nodes with actual operations indicated by an enum. We particularly miss this in DimExpr, but the others distinguish operators by type too (they just have a common supertype). done in: r3167~r3170

Others

  • Always provide a fixity for an Op. done in: r3120
  • Encode Enclosing in some way so that there's a common naming scheme. done in: r3132