I submitted an application at sourceforge.net to get a project page for xX. When typing the comprehensive description I realized it's quite a project! I've never created anything like this before. And I'm only a novice at C. HAHA! That's why I can't wait to create the dictionary object (most likely a btree). The dictionary will play an important part since it will be used by the vm to perform object definition lookups. I already have the stack object. After another sleepless night, mostly thinking about xX, I thought of more things...

Executable objects
Recently, I mentioned that I needed a way to determine whether an object in a slot is data or a pointer to a function. Well, I think I found a solution. First, make the slots store xxObjects and only xxObjects. Then, create what I like call executable objects. xX is typeless so an executable object is simply an object that responds to either the executeNative or executexXe (I will now refer to xXasm as xXe) message. If an object responds to executeNative, that means that it contains a pointer to a function that needs to be executed. This is how native (compiled) code will be executed. It an object reponds to executexXe, that means it contains a xXe code. I modified the messaging model. All messages simply execute a lookup in the current object's slots dictionary for an object. If an object is found, it is placed on the stack awaiting for more messages. The virtual machine will check every object to see if it is executable, and execute it if it it.

xXe Language
Yes, forgive, I changed the name to something I think is more appropriate since xX will execute this code directly. In addition, I improved the language syntax!
[object | object reference] [@|!][message]
That's it! It's extremely simple!
Symbols include:

• @ - Sends a message to an object.


• ! - Sends a message to an object, but prevents the vm from attempting to execute the object.


• {} - Used to group together a collection of objects (I think)
  
• "" - Used by the vm to create String objects. (I really didn't want to do this, but had no
  choice)

Here's an example of what xXe code may look like.The infamous "Hello World!"

"Hello World" IO @stdio

The first command is "Hello World" which intructs the vm to create a String object by making a copy of String and setting its value to "Hello World". The second command is IO, which is the object used to get data in and out of xX, like files, printing to the terminal, etc, gets placed in the stack. The IO object, like the String object is loaded by default by the vm. So now we have at least two objects in the stack. The third instruction is @stdio which instructs the vm to send the stdio message to the first object on the stack, which happens to be IO. IO, like any other object responding to a message, simply pushes an object on the stack. In this case, an native executable object. When the vm realizes this, it executes the native code. And bam! We get "Hello World" on the screen!

Now, for another sample

Object @copy
"Person" xxstack @swap @define
"My Name" "name" Person @define
Person @name IO @stdio

Can you guess what the code above does?

1. Make a (shallow) copy of Object, the grandfather of all prototypes. It actually performs the copy operation!
2. Create a string with value "Person", swap the two newest stack entries leaving the new object first, and send the define message. This grabs the first object on the stack (our copy of Object), uses the second object as a key (the string "name"), and the third object as the value (string "Person"), and create a new slot.
3. Sends the "name" message to our newly-define object, Person. And then prints its value "My Name" on the screen.