ConteX programming language

« March 2005 | Main | May 2005 »

April 26, 2005

Release 0.38 (Eagle)

ConteX 0.38 'Eagle' is out, introducing object oriented programming with simple delegation, and many other small conveniences. All of the foundation is in place for a showcase of true power to come in 0.39

I started by making sure I could build java objects of any kind in CX. If you look at the first half of my unit test file for 'object construction', you'll see examples of objects being built from the java foundation. I feel no need to go into detail about how this is implemented because nothing could explain it better than reading my code.

The second half of that very same unit test file does some object oriented programming. Since this feature was just introduced into CX, it is only being tested for bare-bone sanity, nothing fancy. I will fully exploit this object oriented power in CX throughout the next release, attempting to figure out the best conveniences to add.

This barebone object oriented programming enabled in CX ultimately allows one to do anything found in, say, java's object oriented programming.

(cx:) make["myObject" new-context] (makes a new context, delegated directly to the lobby)
(cx:) inject[myObject {make["f" 4]}]
(cx:) from[myObject "f"]
4

new-context, inject, and from are the main new words in CX. new-context uses the java object creation I made earlier to create a brand new instance from the Context class . Use make or set to give the new context a name, which you will use to refer to it. Now, you can run code inside that object with inject! Using from, you may refer to any variable or call any function you may have injected into that context.

All of the fancy features to come in CX will be built off these 3 words. ConteX 0.39 'Falcon' will exploit this power to the max, attempting to acheive as many conveniences found in other prototype-based object oriented languages in regard to the OO itself. Expect constructors, user-defined types, unions, interfaces, etc.

In addition to the exploitation of object orientation in CX, Falcon aims to provide as much as needed for CX to be useable for other projects. Expect threads, method inlining, in-console help, and then, finally, some libraries that will provide easy access to foundation code like the Swing library, and java.io. The method inlining is my first whack at optimization in jcx. Though jCX is already fast enough for many applications, the method inlining should more-than double the speed. I'll consider bytecode compilation, but it may not be worth the work.

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

April 18, 2005

0.38 'Eagle' alpha screenshot

Eagle introduces creating java objects (still using the two primitive functions: invoke and invoke-static). There is more CX code than Java code now.

Posted by Rex at 04:40 PM

0.37 'Dove' screenshot

Sports the new REPL- a runtime where there are only two primitive actions: invoke and invoke-static.

Posted by Rex at 04:23 PM

0.35 screenshot

This is CX before rebirth. It was colorful and fancy, and wrong all over.

Posted by Rex at 04:04 PM

ConteX Developer's Guide

The ConteX developer's guide: PDF
It is still in progress (about 35% done).

Posted by Rex at 12:53 PM

April 14, 2005

CX 0.38 half done

Im half done with 0.38 'Eagle'. The goals grew, as I've detected a simple design flaw that I needed to nip fast before I built upon it. Therefore, the prototype based OO and user defined types were delayed until 0.39.

Before I noticed the design flaw, I accomplished the building and access to arrays, and started on the construction of other objects (which will be done soon):

(cx:) make["ar1" array[ "this" "is" "my" "life"] ]
(cx:) ar1
array[ "this" "is" "my" "life" ]
(cx:) nth[ar1 3]
"my"
(cx:)

Isn't that awsome? The array, when printed back, appears as the code required to build the array! The main reason this is done is because it simplifies the expirience with the language. It shows a precise correlation with the construction of the entity and the entity's appearance after construction. I'll be continuing this throughout the rest of CX.

Also, notice that the array index starts with 1 and not 0. All index values in CX will be counting numbers. I believe this is a way to rid the mocking of low level languages ( like C ) where indexes start at 0 only because of the pointer arithmetic involved in arrays. Pointer arithmetic is hidden from the CX programmer.

Eagle will be release as soon as I finish all-around object constuction and allow easy access to all of the java collections.

Now, the problem with CX. In Dove, there are two possible tags for the quotes: @ and $. @ meant scoped, and $ meant unscoped. Each quote would keep track of the number of times the word 'inp' is used in the quote, and if that quantity is more than 0, the quote would be declared to be unary (taking input). The problem with this is that one may want to have a function that uses the 'inp' of its surrounding context. For example:

(cx:) make["tell-inp" @{ print-line inp }]
(cx:) make["inp" 3]
(cx:) tell-inp
(cx:)

What happened here is that tell-inp required input and is not waiting for it. I wanted it to print 3, but since 'inp' was found in it, it became a unary function. I first thought this auto-input thing was going to be great. So I took a break and sat around thinking about how to preserve this remote-context word definition power, without any crappy overlapping of inp's... then a solution hit me. here is my dream (this is a fantasy, and will work when CX 0.39 is released) :

make["my-function" @{
expand-inputs this
println arg3
}]
my-function[ "my" "life" "sucks" ]
computer prints: sucks

What in the world was expand-inputs and where did arg3 come from? expand inputs would be a decorator, which is a function that defines words in the given context. It is not really specially marked as a decorator- that is just a term to use for eliminating confusion about a function's purpose. expand-inputs would look like this:

make["expand-inputs" @{
make["the-context" inp]
make["num" 1]
each[
{
make["var-name" string-cat["arg" to-string num]]
make-in[the-context var-name inp]
inc "num"
}
the-context
]
}]

So far, all of this code would be in the same context. CX is dynamically scoped, but has a special feature to spawn lexical boundaries between chunks of code. To do so, you pass a code block to context: , and that block then becomes the constructor for a context. When this is done, all of the variables begin to persist, and the new context cannot refer to anything in the current context, unless this context is passed as an argument. Let's reuse my-function as a constructor to build a context and refer to something inside of it.

make["my-context" context:{my-function["a" "b" "c"]}]
computer prints: c
from[my-context "arg2"] => "b"

I made a context which continued to exist as my-context. I'm not sure if I'll call it 'from', but that is the way to call/refer to functions/variables in another context. 'from' would be built with a primitive for running a quote inside another context:

make["from" @{
expand-inputs here
remote-eval[arg1 arg2]
}]

Finally, the difference between here and this is important and can help you understand contexts even more. When the function 'context:' is given a quote with a call in it, a new mapping of variables-to-values is created. Within this new context , 'this' refers to that context itself. If the code was run without being passed to context:, it would make a new scope, but not a new context. 'here' refers to the current scope. 'this' refers to the current context. I may change these two to this-context and this-scope.

All of this context stuff is well-thought-out after I took a good break from coding CX to relax myself and take every route possible (mentally) as I also play with Factor, Slava Pestov's language which exploits the power of concatenative programming and factoring out code.

Posted by Rex at 08:47 PM | Comments (0)