The Merging Pot

Since Freya is a split language, the compiler must merge different parts of the source code. We have a handful of syntactic structures that require merging:

• First, each class declaration must find its corresponding implementation section. Both parts should be located in the same source file.
• Each event, property and method must match its implementation.
• Methods, events and properties from the implementation that don’t match with a declared class member, are added as private members of the class.
• Finally, there are features that always belong to the implementation section: class constructors, and interface delegations.

Easy? Well, not at all. Suppose we have this declaration:

method WhatEver(I: Integer): String;

Does this method match with the following implementation?

method WhatEver(I: System.Int32): System.String;
begin
    ...
end;

Now you can see the problem: a type reference may omit the namespace thanks to a using clause, and several primitive types have synonyms. That’s the reason why we can’t merge method implementations when we match a class with its implementation section. We must register namespaces and types, both from the referenced assemblies and user declarations.

Please note that we face a similar challenge when identifying a class implementation section. This is the easiest case:

namespace Freya.DataStructures;
public
    MyClass = class;
implementation for MyClass is
    ...
end.

But, what happens when we find this?

implementation for Freya.DataStructures.MyClass is

To avoid complications, Freya requires that the type reference in the implementation header should not include the namespace part.

Another Freya feature complicates things: nested type references. You can declare a nested type along with the enclosing class, as in C#, but you can also put a simple stub inside the enclosing class declaration and declare the actual type later.

LinkedList = class[X]
protected
    Node = class;
    ...
end;

LinkedList[X].Node = class
    ...
end;

The implementation section for the linked node class should be like this:

implementation for LinkedList[X].Node is

Have you noticed I didn’t mention merging any namespaces? I could declare types belonging to the namespace Freya.DataStructures in several source files? Should we merge those “partial” namespace sections? No, we shouldn’t. Each namespace section may have different using clauses, and these clauses plays an important role in the resolution algorithm.

Actually, we’re missing another merging algorithm: gathering parts from a partial class. So far, we haven’t added partial class support to Freya. We’re planning their design and implementation in the short term.