An extensible FARG implementation, Part II

[Microsoft Word seems to be messing up my fonts. Apologies.]

The question I explore in this post is how much and what can be shared between CRCC projects. I will try to stay as concrete as I can. In this post, I have managed to talk about a single “simple” aspect.

One of the most obviously sharable aspects of FARGitecture is the codelet system. I am not referring to the types of codelets, but rather to the infrastructure for dealing with codelets. If a good, solid, and reusable framework had been available to me, it would indeed have saved time. My final implementation is only a couple of hundred lines of code, but the effort required and mistakes repeated make it quite costly. Needlessly costly.

What are the petty things needed of this infrastructure? Obviously, we need a simple interface to add codelets and select codelets. That much is obvious. What may become more apparent only by implementing a system and struggling to grapple with its complexity are other features and tools, like the following (and I have not counted these “optional” features in the 200 lines I mentioned):

  • We need the ability to remove stale codelets. When a Codelet is added to the Coderack, it may refer to some structure in the workspace. While the codelet is awaiting its turn to run, this workspace structure may be destroyed. At the very least, we need code to recognize stale codelets to prevent them from running.
  • Writing new codelets should be easy. Most codelets, when written in the programming language being used, share boilerplate code. Tools that allow us to write closer to the domain (and then compile our code down to the programming language) have proved very useful to me. They improve code readability, lower the barrier to experimenting with new codelets, even improve error messages. Just to illustrate, here is the code for one codelet type:

    CodeletFamily flipReln( $reln ! ) does {
    RUN: {
    my $new_reln = $reln->FlippedVersion() or return;

    Mind you, I am not claiming this to be hard or undoable by appropriately setting up classes so that the “compiler” is not required. It is not difficult, but it takes careful thought and time. I am just pointing out that something needs to be done to ease codelet writing.

  • Seqsee has the notion of scripts. Some tasks are by their very nature somewhat serial. Like makings tea. Or describing a solution. How would a FARGitecture do such tasks? Certainly not by using a single codelet. We do not need a “make tea from scratch” codelet, or a “write dissertation” codelet. Seqsee “solves” this (ha ha) by splitting the task into several codelets that call each other. Painful to write? Yes. Repetitive to code? Yes. Extend the programming language to reduce busy work? Yes. So here is Seqsee’s code for one task (which is a subtask of a bigger task, but we don’t have to care).

    CodeletFamily DescribeRelationCompound( $reln !, $ruleapp ! ) does scripted {
    STEP: {
    my $category = $reln->get_category();
    SCRIPT DescribeRelnCategory, { cat => $category };
    STEP: {
    my $meto_mode = $reln->get_meto_mode();
    my $meto_reln = $reln->get_metonymy_reln();
    SCRIPT DescribeRelnMetoMode,
    meto_mode => $meto_mode,
    meto_reln => $meto_reln,
    ruleapp => $ruleapp,

    The SCRIPT calls launch other codelets, which may call more scripts, and return. All along, all the laws of codelets hold: they can be removed from the Coderack without being run, several “scripts” may run in parallel, and so forth. Again, being able to focus at the task on hand is a big win.

  • At any stage, several codelets are on the Coderack. Several avenues are being explored in parallel. In order to understand what’s going on, or even to demonstrate what’s happening, we can build tools. These are only related to the codelets, and can be completely domain independent. Here are some such visualizations from Seqsee.
    • Codelets launch other codelets. By logging what codelet added what other codelet when, we can obtain trees of codelet launching. Very useful for debugging. This image is from a tool that allows exploration of such trees, allows searching for specific types of codelets, and also lets us see how long codelets sit on the Coderack.

    • At any stage, there is pressure to do several things. Each codelet is a tiny bit of pressure. The log mentioned above also allows us to create graphs that display the change in pressure to do a particular thing over time.

      The image below shows the pressure to extend groups during a single run.

All tools mentioned here are domain independent. Just writing the system that manages the infra takes little time, but writing tools takes longer. And deciding what tools to build takes longer still, and yet, in the long run, they save time. Without these tools, I may not have been able to write Seqsee.

Imagine writing a FARGitecture to be like programming a task. Well, don’t imagine, it is programming a task. Except that we design it from scratch: we build our own virtual machine, write our own tools. It is high time we had a shareable toolset, at the very least.

I will end by pointing out that the images I have added above were generated from a log file. This file could have been dumped by a COBOL program, if somebody wanted to write a FARGitecture in that wonderful language. We don’t need to agree on a programming language to share tools.

Explore posts in the same categories: Architecture, Author: Abhijit Mahabal

2 Comments on “An extensible FARG implementation, Part II”

  1. Eric N. Says:

    Thanks for these two posts. A few responses: I like what you said about generative the images from your log files. My default plan is to write similar log files as XML, because many languages give you reading and writing from XML for free — I can generate the log files with almost zero code. The structure of XML should make it easy to write language-independent tools for analyzing the data.

    I put in placeholders in my domain-independent library for the two graphs you show above as soon as I saw them running in your program. They seem quite useful.

    For writing new codelets, I’m trying a combination of using a Workspace and Slipnet API that is easy to call from a new codelet, as well as a set of custom attributes (the .NET language construct) that I can attach to the Codelet subclass definition or particular methods like Run. These custom attributes, along with deriving from the base Codelet class, should make my coding analogous to what you’ve done, in terms of reducing repetitive code, etc. But that’s not done yet so I’m not sure how it’ll look in the end.

    I like the script idea too, and I’m thinking about how to incorporate that at a later date. Probably I’ll end up using some “design patterns” idea, but I’ll have to understand your scripts more fully first.

  2. […] Though I’m not coding this right now, I think my sketched solution might even help the stale codelet problem Abhijit mentioned: We need the ability to remove stale codelets. When a Codelet is added to the Coderack, it may […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: