« November 2004 | Main | March 2005 »

February 23, 2005

At the peak

So the hard work was done: creating a system that executed lists from the inside outwards in a linear way that never uses recursive java methods. How? I use a linear method of evaluation that rewards tail call elimination and lists that refer to themselves.

CX syntax requires the runtime to use an algorithm that isn't commonly used for evaluation. It all starts with the parser, really. My parser produces an AST that doesn't notate function calls and arguments. There is no a(x) in cx, there is only a x , and only if 'a' happens to 'take input' at the time of evaluation, a(x) will happen. This leads to an algorithm I've concluded to , which introduces some new terms to the compiler conversations I take part in. I feel a need to define my algorithm in detail.

The overall sections of CX evaluation are as follows: Syntax is put into the parser, which produces the AST, which is sent to the evaluator and evaluated.

The parser uses a state machine to tokenize the syntax. The state machine also tells the parser when to go 'up stack' and 'down stack'. Up stack is when a '[' or '{' is encountered. The parser pushes a new Quote or List into the parsing stack, and continues to iterate over the text, pushing tokens into this list , using Stack.peek(). When a ']' or '}' is encountered, the state machine reports a 'down stack' which triggers the parser to pop the list from the top of the parsing stack and add it to the top of the stack. Here is a psuedo-code explanation of a 'down stack' operation:
((Collection)parsingStack.peek()).add(parsingStack.pop());

(I stopped writing this because it's better to be put in a manual or something...)

Posted by Rex at 01:09 PM | Comments (0)

February 02, 2005

Inches away from the peak

During the redesign of my code base, I've rearranged and optimized the project's file structure, java class names, and the code balance between the implementation language and contex itself.

Everything started with deleting much of my java code. Now, almost all operations boil down to the 'invoke' primitive, which recieves an object, a method name and a list of args. Sounds familiar? This primitive is just a CX wrapper for accessing java reflections, hence instantly giving CX all of the powers of java to build upon. This leads to almost all of the code being made in CX, all sitting ontop of a simple java application which allows the cx code to control the java runtime reflectively. The advantage is that the CX code will end up making a complete runtime out of a small set of code in another language than java, just like it expects little from java now.

The first thing to sort out is how to use this 'invoke' primtive to build CX all the way back to the functionality that it had back when the design was not portible to another implementation langauge. These things include 'set' and '@'. The struggle is to have less primitives.

Once I would have made what was once considered primitives in CX, I will need to play around to figure out the best Object system. The best way to figure it out is by testing out different ways. ConteX is an object oriented programming language, that much is known. The goal will be multiple inheritance by sharing lists of methods, direct object copying.. I dont know how it will work out, but I am stiff with a set of beliefs.

On a higher level, the math lib is being done in CX too, for the same advantage: portible power.

Posted by Rex at 12:59 PM | Comments (0)