So I am narrowing down my understanding of how to use mixins. The Comparable example is awesome, but does not need fields. In my effort to reduce the size of the average mantra object, I needed to remove the in and out fields from every object. The should be moved to an element that all of the actors can include or inherit from. I did not want to force all actors to inherit from the same base class, so I decided that a mixin was perfect but mixins don't currently allow fields. I spent three hours yesterday adding fields only to discover that, while I can get it to work, they are extremely inefficient because I need to use general message sends to call accessor methods. Blech.

Consequently, I am going to literally make the includes keyword include/copy all of the elements from the mixin into the requesting class. The key is to have a single place where the programmer can specify the Actor. Whether I do an actual include or a shared delegate is merely an implementation issue. For speed, I am going to use an include mechanism. I will back out all of my changes from yesterday.

I also noticed that mixins can also act as interfaces. Any class that includes the Actor mixin is also known to answer all those methods and have fields potentially; the fields I will have to access with getters because Java does not allow fields in interfaces. This also gives me a mechanism to describe what an input or output stream looks like. Right now toInputStream(), for example, returns a plain object when I really want to return InputStream. I can make InputStream a mixin with my new mechanism and then I can use the generated interface to make Java to direct method calls instead of mine general message send.

My development plan for the morning is then:

1. make a copy of work yesterday and then back out the changes
2. make the semantic analysis phase decorate the symbol table with tree pointers so I know what code implements that symbol.
3. add fields to mixins in Mantra.g, SemanticAnalysis.g, CodeGen.g
4. In CodeGen.g have it generate code for the included methods and fields; tried to make the templates ignorant of the addition by manually invoking the appropriate tree grammar rules to generate code. The pointers to the appropriate method and field ASTs are obtained from the symbol table modifications in (2).
5. Alter code generation so that mixins results in interfaces rather than static classes.
6. Allow the name of a mixin as a type name; this should already work, but test it

Here is how I want to define an Actor:

package mantra::io;
mixin Actor {
        object in = stdin;   // getters/setters created automatically
        object out = stdout;

        main() { ; }
        object read() { return in.read(); }
        write(object o) { out.write(o); }
}

Then we can do:

class Lines includes Actor {...}