Relevant links:

Class dictionary for class dictionaries:
http://www.ccs.neu.edu/research/demeter/software/docs/src/generate/generate.cd

ICSE keynote on LoD:
http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf

In DemeterJ we also use the class view and the module view
simultaneously. The class view is given by the class dictionary
and the module view by the behavior files. 
But the class view is not faithful to what is in the 
behavior files. For example, when a class is added in a
behavior file, the class dictionary is not updated.
Only the "low-level" Java classes. But for some purposes they
are not low level!

DAJ and XAspects have a similar problem.

If we treat syntax as an aspect, it becomes easier to 
add to the class dictionary incrementally.

extract-edit-absorb cycle: we don't have it.

What is easier in the classes view?
Adding an additional class, e.g., UnaryOperator.
We can implement all methods needed in the class and
don't have to go to the printing module, evaluation module,
T1-V1 module, T2-V2 module etc.

What should the views be in DAJ:

class graph (.cd)
syntax aspect: turns class graph to class dictionary (.syn)
intertype declaration aspects (.aj)
strategies, traversals (.trv)
visitors (.java)

What we want is that we can add a class to the class graph
or make another change to it
and then the tool will lead us through all the files (other views) that
might need updating.

===========

syntax as aspect:

Write a class dictionary: will automatically produce
the syntax file. Will have to assign tokens to parts.
There are many ways of writing the syntax aspect: 
different groupings.


===========

Different kinds of aspects:

cd for language L dealing with concerns Cs.
Need to express enhancement outside language L: define L'
to deal with a new concern Cnew.

To express enhancement to cd of L, we don't use a
cd' of L' because this would be a violation of LoDC.
Talking means: referring to new non-terminals.

Instead we invent a new aspect-specific language D for expressing delta.
What is the design space for D?
We can refer to concrete syntax or abstract syntax of L
or a combination of both.

Example: syntax aspect:

extend: Part | OptionalPart with Syntax:
Part | OptionalPart | Syntax:

Syntax now appears in a list ...

This is not right!

Should use: Sandwich2(Part) | OptionalPart
Sandwich2(S) = "(" List(Syntax) <inner> S <second> List(Syntax) ")".
// change syntax for cds to express to which part syntax belongs.

leads to:
before/after ClassName.ClassPart (only for required now)

in ClassDef:

ClassParts -> Sandwich(ClassParts)

leads to: before/after ClassDef

--
for optional parts:

before/after ClassName.ClassPart (optional) 
--
before/after RepetitionClass.OuterSandwich

before/after RepetitionClass.InnerSandwich

or

before/after RepetitionClass {

before/after RepetitionClass }

Using the first approach is more systematic.

================

In other situation, the extension is not done through a language
extension but by adding statements in the same language:
AspectJ: base plus aspect
DAJ: traversal plus visitor

================

But we can simulate  language extension for the Demeter case:

Java Language Fragment:

Method = MethodSignature MethodBody.
MethodBody = List(Crossing).
Crossing = Source Label Target.

Sandwich(MethodBody)
Sandwich(Crossing)

Sandwich(S) =
  <upper> List(Statement)
  <inner> S
  <lower> List(Statement).

AroundSandwich(S) =
  <upper> List(Statement)
  <inner> Conditional(S)
  <lower> List(Statement).

before/after MethodBody
before/after Crossing

======== 
Also factor out pretty-printing aspect.
How do the three aspects interact?
How is that related to the language extension grammar?