Dashboard > People > Terence Parr > Browse Space > News from
  Terence Parr Log In | Sign Up   View a printable version of the current page.  
  News from October, 2007
  2007/10/02

Check this out:

ErrorMgr errors = ErrorMgr(); // answers error()
Vehicle.delegate(errors);
Car c = Car(); // car does not answer error()
c.error("we crashed");

here I am calling the delegate method on the Vehicle class, of which Car is a subclass. I make an instance of a car and then send it the error message, which is forwarded to the error manager. Here are the other definitions:

class Vehicle {
    string color;
    string brand;
}
class Car extends Vehicle {
    float mpg;
    int numDoors;
}
class ErrorMgr {
    error(string msg) { println("error: "+msg); }
}

This is a delegation scheme per class not per instance. All instances of Vehicle share the same delegate, but subclasses can override. If there is no delegate for an object's class, the message is forwarded up the class inheritance hierarchy. So, for example, you could add a delegate to object that all instances in your program could access my method.

I'm now working on a dynamic mixin facility, which differs from a dynamic delegation in that the mixin knows which object forwarded the message to it. The 'this' pointer of the delegate must be the usual whereas a mixin is assumed to have a 'this' pointer of the delegator.

By the way, I'm going back to calling mantra's mixins "mixins". Use "include" to bring in methods:

class int includes Comparable {...} // statically mixin Comparable's  methods
mixin Comparable {...}

Now I just have to update the doc to include all of the changes I've just made. I even added a meta object protocol, the natural place to store delegates per class. Getting verrrry close now.

Posted at 02 Oct @ 8:19 PM by Terence Parr | 0 comments
  2007/10/03
Last changed: Oct 03, 2007 14:07 by Terence Parr

Awesome. Mantra does a dynamic mixin. Just map a string to a closure with "self" as first arg:

int.mixin("toHex",
   {int self | return java {new mstring(Integer.toHexString(((mint)self).v))};}
);
println(32.toHex()); // emits 20, the hex verison of 32. :)

also note you could alter the MetaClass per object (set .class field) to alter behavior per instance! You can ask about meta object now:

println(32.class); // emits <int>

To avoid strange bugs, you can only add not override/alter behavior.

Posted at 03 Oct @ 2:04 PM by Terence Parr | 0 comments
  2007/10/05

Finally got something ready for people to look at. Main components are in.

http://www.linguamantra.org/

Posted at 05 Oct @ 6:44 PM by Terence Parr | 2 comments
  2007/10/08

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 {...}
Posted at 08 Oct @ 10:23 AM by Terence Parr | 0 comments
  2007/10/11
Last changed: Oct 11, 2007 12:22 by Terence Parr

I replaced my blocking queue sitting between pipeline actors (threaded consumer/producers) and speed of my word freq program dropped from 5.2s to 3.5s on 5M file simply by replacing the blocking queue with my new ping-pong buffered version. That is close to the 3.0s achieved by the nonthreaded version.

// threaded, pipeline version; 3.5s (from 5.2s) on 5M file
f => Words() => { string w | ... }
// nonthreaded, nested map operation on big list; 3.0s
f.lines() => a;
a:{ string line | line.split():{ string w | ... }};

Buffer size is 1000. When I drop to 100, slows down by .2s. When I increase to 4000, no change. 40000, slows down by .5s. Size 400 seems to be slightly faster. Default queue size set to 400 now.

Thanks to Sriram Srinivasan for the idea of ping-ponging the buffers.

Posted at 11 Oct @ 12:12 PM by Terence Parr | 2 comments

October 2007
Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Oct 03, 2007
Oct 08, 2007

Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.1 Build:#806 May 06, 2007) - Bug/feature request - Contact Administrators