Interpreting the Language
While the ctalk language itself is far from complete, the interpreter design provides the basic functions of an object-oriented language interpreter. Listing Six shows the "Hello, world" program written in ctalk.
Listing Six
Object method set_value (char *s) {
self -> value = strdup (arg(0));
}
Object method value (void) {
return self -> value;
}
Object class HelloClass;
int main (int argc, char **argv) {
HelloClass new helloObject;
helloObject set_value "Hello, world!";
printf ("%s\n", helloObject value);
return 0;
}
The interpreter uses only three primitive methods written in C: "class," "new," and "method." The interpreter includes their initialization functions in the output program's initialization code, as well as the definition of the "Object" class.
The function resolve(), in class.c, which is too lengthy to list here, does the work of resolving objects and methods. Although it might be desirable to write the function using a structure similar to that of is_c_function_declaration() in Listing Four, resolve() relies on scanning the message stack frame and hands off interpretation chores, like argument processing, to other subroutines.
The design of the "method" primitive also allows operator overloading. If the input source code contains a method declaration such as the following, the interpreter treats it as an overloaded operator, using "+" as an alias to the function "plus" instead of a C language statement:
Method + plus (int a) {
}
In most cases, the interpreter evaluates primitive objects and methods the same as objects declared in the input source code. When the interpreter encounters a label, it determines whether the label is a reference to an object. If the interpreter finds a label followed by another label, it looks for a method in the preceding object's method dictionary, or in the method dictionary of the object's superclass.
When resolve() locates an object reference (for example, the label "Object" in the statement "Object class HelloClass"), it sets the corresponding message's value to the object, as shown in the following program statements:
if ((result_object = get_class_object (m -> name)) != NULL) {
m -> obj = result_object;
return result_object;
}
Then, when parser_pass() calls resolve() with the stack index of the next label, the message for the method "class" in this example, resolve() scans back to find out if the reference to "Object" has already been resolved.
resolve() then checks whether "class" is a method in "Object"s method dictionary, and if so, it performs the following statements—the message m in this case contains the method:
if (!strcmp (m_prev_label -> obj -> classname, "Class")) {
if ((method = get_method (m_prev_label -> obj, m ->
name))
!= NULL)
{
m -> receiver_msg = m_prev_label;
m -> receiver_obj = m_prev_label -> obj;
m -> tokentype = METHODLABEL;
}
resolve() does the same for instantiated class members such as helloObject. In these cases, resolve() sets the method message's token type to METHODLABEL and sets the message's receiver_obj member to the "Object" object referenced by the previous message's obj member. This simplifies the statement's processing further on.
If possible, resolve() immediately processes the method message. In conceptual, object-oriented terms, this step is known as, "sending a message to an object." In ctalk's case, a simple function call with the method and its receiver object is sufficient.
The method_message() function performs the work of executing the method, if it is a primitive method. If the source code contains the method definition, as in the case of "set_value" and "value," the interpreter inserts the runtime function call into the output, along with the function calls that save the method's arguments both in the method's internal dictionary and on the runtime argument stack.
Because resolve() also sets the method message's receiver_msg member to the stack index of the receiver message, the methods and method-call protocol can set the value_obj of the expression to the statement's value, as in the case of the "new" primitive method, which also sets the class and scope of the new object, and store it in the interpreter's dictionary:
m_receiver -> value_obj = arg_object;
The method-call protocol also sets the evaled message member of each of the statement's messages. If the parser encounters the statement again, it can use evaled to determine if further processing is necessary, or simply retrieve the value of the statement, generally from the left-most message, with the following macro:
#define M_VALUE_OBJ(m) ((m -> value_obj && \ IS_OBJECT(m -> value_obj)) ? \ m -> value_obj : ((m -> obj && IS_OBJECT(m -> obj))\ ? m -> obj : NULL))
The macro M_VALUE_OBJ returns either the message's value object, its object reference, or NULL, depending on how the interpreter processed the message.
The interpreter then, for example, can set the left-most message value_obj of the expression "1 + 1.5" to "2.5" without coercing the argument objects to another class, changing the message's token type, or reprocessing the statement.
Again, by handing off specialized chores to subroutines that evaluate particular statements, like method arguments, the design of the interpreter becomes much simpler.
Code Generation
Generating the ctalk runtime code is fairly simple. In most cases, the interpreter is able to simply replace the ctalk statements with the C language function calls for ctalk's runtime functions, in ctalklib.h.
As previously mentioned, C source-code modules do not need drastic changes to use ctalk. GCC compiles C source-code modules after processing with ctalk without additional changes.
As the ctalk language is in an early stage of development, the language imposes a few restrictions of its own. Ctalk does not, at this point, process objects and methods declared extern, and the program must declare methods and global objects in the preamble of the source module that contains main().
In addition, because GCC is the compiler used in ctalk's development, declarations of local objects must occur after the C variable declarations or GCC will produce a syntax error.
The runtime library uses a slightly different interpreter scheme than the ctalk program. It contains stacks only for receivers and arguments, at least at this stage. This design simplifies method calls considerably. The ctalk library implements the keywords self (equivalent to this in C++) and arg as macros.
Conclusion
The ctalk language demonstrates how a frame-based, message-passing parser can provide a simple method to analyze program statements semantically as well as by using language syntax. The designs of the parser and the corresponding interpreter are flexible enough that the program can analyze ANSI C and ctalk statements and generate code that provides the object-oriented language's extensions within the C-language source code.
Robert Kiesling is the former maintainer of The Linux Frequently Asked Questions with Answers Usenet FAQ. He can be contacted at [email protected].
