%%%
%%% DL Nov 20: subtitle changed
%%%
\Ssect{{\longAC} compiler}{langnotes}

\begin{figure*}[!t]
\figfrom{implsketch}
\caption{A data flow over-view of the compiler for Aspectual Collaboration.}
\label{Fig:implsketch}
\end{figure*}

%There are three interesting facets of the implementation:

% do NOT remove the explanation of the acc acronym. We use it later without explanation.

The prototype {\longAC} Compiler, {\tt acc},   follows a fundamental design: collaborations are compiled separately, and composed at the object-code level.  
The object code the compiler works on is Java byte code, which turns out to be very convenient since it provides a fully disambiguated version of the collaboration.  
Byte code is managed as standard Java \java{.class} files, which results in easy renaming of members, re-targeting references to point to other members, and moving call graphs from one group of classes to another. 

Figure \ref{Fig:implsketch} is a data-flow road-map of how collaborations are compiled to executable programs.
Rather than compiling the whole language directly, input collaborations are translated into \emph{Core {\ac}s} (CACs), which are transliterated into Java, compiled, and finally manipulated at the bytecode level.
As several important steps will be elided in the following presentation, we refer the interested reader to the compiler itself \Cite{acc-www}. 


%\Ssect{Atomic Collaborations}{atomic-impl}


CAC participants are compiled by transliterating them to Java and compiling with an off-the-shelf Java compiler.
The transliteration replaces \keywrd{collaboration} with \keywrd{package}, \keywrd{participant} with \keywrd{class}, comments out all additional keywords we have introduced (such as \keywrd{aspectual} and \keywrd{expected}), and creates stub bodies for expected methods.  
After compilation, the \java{.class} files are annotated according to the commented-out  keywords, to allow the compiled collaboration to be treated correctly in subsequent stages without requiring manifests or interface files to be maintained in the file-system.
The JVM definition \Cite{JVM} requires that a JVM ignore all annotations it doesn't understand, ensuring that the compiled collaborations consist of 100\% legal {\tt .class} files.%
\footnote{
%
        Having collaborations be legal Java packages leads to an unintended but useful feature:  by letting expected methods optionally have bodies, we can unit test collaborations in isolation.
        The optional body acts as a custom stub---it doesn't affect how the methods are treated, but by careful implementation of stubs, we are able to execute and test the collaboration before all required interfaces have been fulfilled.
%
}

%\Ssect{Composite Collaborations}{composite-impl}

To compose two collaborations according to an attachment, we first generate output participants.
%% Nov 15: clarify
CACs do not have \keywrd{extends} clauses, instead having explicit definitions of all participants, including those representing reified methods and return values. 
These are compiled as per the atomic case.

Each constituent collaboration is then inserted into the output collaboration, according to the participant map of the attachment.
Each constituent participant is inserted into the appropriate output participant, with each of its members renamed to names which are both fresh (to avoid name clashes) and illegal in Java (to avoid spurious name clashes).\footnote{The JVM has a larger set of legal identifiers than Java does.}
References to participant types and member names are systematically renamed to maintain collaboration internal references.
We'll call systematic renaming of an entity and all references to it \emph{alpha renaming}.
Alpha renaming is possible because {\ACs} are closed: the compiler will be able to statically find all references by searching all participants in the collaboration.

Some care must be taken not to break overriding relationships: methods must be renamed like the methods they override.
If a method overrides an external method (such as \java{toString}), it cannot be renamed at all, and  name clashes can become unavoidable.
In such cases manual disambiguation is required.
Java constructors have similar restrictions (all constructors are hard-wired with the name \java{<init>}), in addition to restrictions on how they can be invoked.

References inside the now-populated participants are redirected as per the attachment specifications. 
Exporting a  member is implemented by alpha-renaming the member to the exported name.
Providing a member to an expected member is implemented by redirecting all references from the expected member to the provided member.

Aspectual methods' interception of method executions is implemented by
generating a collaboration with three participants corresponding to the
the host participant and two reification participants.  The generated
collaboration is based on the signature of the now known host method.
A new intercepting version of the host method is generated,  whose
body instantiates the reified-execution participant, storing in it
the receiver and arguments to the method call, and passing it to the
aspectual method.  The reified method participant's \java{invoke} method
invokes an \keywrd{expected} method that will be mapped to the original
host method, passing it the captured arguments, and instantiating a
reified return object with the results of that call.  Lastly, the now
generated collaboration is composed into the output collaboration as
if it were a manually written collaboration---requiring no special
language support---so that the new host method is exported to replace
the original host method, and the original host method is provided so
that \java{invoke} can access it.

The generated code needs to be carefully crafted to catch exceptions
and null values, but contains no locations where dynamic errors (such as
casts) can occur.  Notice also that the scheme requires no modification
of either the aspectual method nor the host method: the extent to which
the composition modifies object-code is to redirect references to members
and types.

%Combined with lack of casts, this motivates our claim of type safe separately compiled advice

%%%
%%% DL Nov 20: subtitle changed
%%%
\Ssect{Future work}{future}

There are several subtle implementation issues that need to be dealt with
in future work.  These are issues that we have solved at the language
design level, but not yet implemented.

\ssssect{Parameterization.} 
By adding types to collaborations, it becomes feasible to express attachments which are abstracted over the exact collaboration attached.
By passing collaboration-valued parameters as arguments to attached-collaborations, very complicated behaviors can be succinctly expressed. 
The challenge is to develop a type system that allows flexible use while capturing errors early.
Errors will always be caught at compilation time, but it is desirable to catch them when the parameterized collaboration is defined, rather than used.

\ssssect{Point-cuts in the interface.}
The interface to an {\ac} currently contains only participants and members.
In order to add advice to a member, it must be in the interface, and hence be visible. 
It is desirable to decouple these concepts, by putting sets of execution points that can be advised directly into the interface of an {\ac}.
Such sets of  points correspond to point-cuts in {\aj}, but will generally be sets of tuples of points rather than singleton points (a singleton point is a special case of a tuple).
We are currently investigating the precise semantics of such a system, and are in the process of investigating what repercussions such a change implies.

\ssssect{Constructors.}
The main problem with constructors is that they are the only methods which should be merged, rather than kept separate. 
When two constituent participants are mapped to the same output participant, we want creation of an output-participant object to invoke all three (two constituent, and one output) constructors. 
Each participant may actually contribute several constructors, which in turn may lead to several inheritance chains of constructors. 
Since a constructor may invoke any method of a class, we have to be \emph{very} careful about the order in which class initialization methods are invoked. 
Our current solution is to have a sensible heuristic, and ask the user to specify in the situations where that does not apply. 
We note that Jiazzi \Cite{McDFlaHsi:Jiazzi} has a similar restriction, requiring all constructors in an inheritance chain to have exactly the same signature.

\ssssect{Cflow.}
{\aj} introduced the \keywrd{cflow} construct for capturing that the target join-point occurs within the dynamic extent of an enclosing join-point---similarly to how one might inspect the run-time stack to see whether a program point is within the dynamic extent of some method. 
We can easily achieve similar effects by generating aspectual methods and attaching them to the enclosing and target methods.
Our systematic reification of method calls make it a natural option to expose the enclosing method call to the target advice as well. 
This opens up the exciting concept of allowing an aspectual method to possibly modify the enclosing method call's arguments, and then restart the whole call chain.

\ssssect{Change the Back End.}
Currently, {\tt acc} translates a collaboration to plain Java, compiles
that, and then works on the generated byte-code for the attachment
and composition operations.  However, the mechanics of the byte-code
manipulation are tedious, and is not the contribution of our research.
Instead it may be possible to offload this development burden to a
back-end based on {\ji}, which would allow us to focus on developing
the module interface language and aspectual features.

%%%
%%% DL Nov 20: subtitle changed
%%%
\sssect{Other extensions}
In addition to implementation issues, the following are natural extensions
to this work:

%\ssssect{Derive Output Participants and Mappings.} 
%The current implementation forces the user to specify the structure of the composed collaboration before starting to attach other collaborations. 
%This simplifies determining whether an attachment has a correct mapping of participant types, but at the expense of programmer convenience: the user likely cares only about a few details of the attachment, but is forced to specify the whole mapping.
%It would be better if the system, given a partial specification, derived an output class-graph that was consistent with the attached collaborations.
%This is likely easier than it first seems, as class graphs have rich internal structure (mainly through method signatures), significantly constraining the search space.

\ssssect{Object Graph Constraints.} A key concept of collaborations is that each has its own class-graph, which are fused when one is attached to another.  
The behavior of a class-graph will in general instantiate classes of that class graph and store the objects in variables. In effect, each collaboration will build its own object-graph. 
In addition to \emph{building} an object graph, the collaboration also makes assumptions about it--these assumptions are encoded in the code of the collaboration, and take the form of invariants over the object-graph.

Examples of invariants are that a non-zero value for one variable indicates that another is ready to be read, or that two variables of the same type in fact \emph{alias} the same object.  The key insight here is that the fused collaborations must make compatible assumptions about their object-graphs, as in addition to sharing a fused class-graph after attachment, they will at runtime also share an object-graph.

It would be helpful to capture these constraints in the interface of the collaboration, so as to be able to catch such attachment errors at compile-time.  This can be seen as a special case of contract checking, where perhaps machine analysis can help derive the object-graph (run-time) constraints to be checked at compile-time.

\HIDE{
\ssssect{Macro System.} We purposefully keep our core language minimal to achieve a simple semantics. 
However, this leads to programming patterns occurring over and over. 
Rather than adding these patterns to our core language, one approach would be to desugar a rich input language (perhaps containing ``before'' and ``after'' advice) into our core.
This desugaring could be written as pre-processing task, but this would force the developers to update it at the whims of the users of the language.
A better solution would be to include a macro language, to allow the users to encode their particular programming patterns. 
However, the requirements of this language have not yet been investigated.
}

\ssssect{Garbage-collect Participants} 
Because collaborations are closed behind an encapsulation interface, we can statically determine all participants and members reachable from the exported interface.
Thus, we can safely remove all non-reachable participants and members, retaining only the exported interface and any non-exported but internally referenced members.
This smaller collaboration is very similar to a teased-out HyperSlice in {\hj}.
To completely simulate a HyperSlice, we would need to add the ability to ``unprovide'' a member---to drop a member's implementation and thus make it \keywrd{expected}: a small modification to the current implementation.


% ---------------------------------------------------------