I agree with Ian, maybe using caps is not the best idea. It reminds be of BASIC which I used to do long time ago :). It also makes the code look a bit scary.

I like the approach and I think it goes close to my earliest proposition and to what I am proposing for the layer committeee ( though we did not have a meeting yet). 
I would though write it in a more Theano like ( Ian has a example of how that would look). I would also drop the CALL and FLIT constructs, and actually have a 
decorator ( or something ) that wraps around a function to transform it into a call or flit. I hope that this is only syntactic sugar ( does this change anything
in the actual implementation ?? ) that makes things more natural. What I want to reach is something that looks very much as Theano, just that now you are creating
the graph of execution steps. Refractoring what you wrote this will look like

x = buffer_repeat( 1000, dataset.next())
train_pca = pca.analyze(x)

train_pca.run()

If you allow a FLIT to also get multiple inputs ( so not just the one) which comes natural in this way of writing you can get to describe a DAG that not only 
describes the order of execution but also deals with what takes data from what. I'm sorry for not being there yesturday, from what I remember I have the 
feeling that for you that is done under the hood and not taken care by this flow control structures. 

To be a bit more explicit, in the way of writing the code above you can see that :
  a) dataset_next() has to run before pca_analyze
  b) pca_analyze needs the result (data) object of buffer_repeat( dataset.next()) 

I've actually elaborated on this idea here and there, and figured out what the result from such a control flow thing is, and how to make everything explicit 
in the graph. Parts of this is in my plugin_RP.py ( Step 1) though it is a bit of a moving target. I also have a sligtly different way of writing REPEAT 
and BUFFER_REPEAT .. though I think is mostly the same. I actually did not know how to deal with distributed things until I saw how you deal with that in your code.
Copy-pasted a version of a SDAA with my way of writing : 

    ## Layer 1:

    data_x,data_y = GPU_transform(load_mnist())
    noisy_data_x  = gaussian_noise(data_x, amount = 0.1)
    hidden1       = tanh(dotW_b(data_x, n_units = 200))
    reconstruct1  = reconstruct(hidden1.replace(data_x, noisy_data_x),
                            noisy_data_x)
    err1          = cross_entropy(reconstruct1, data_x)
    learner1      = SGD(err1)

    # Layer 2 :
    noisy_hidden1 = gaussian_noise(hidden1, amount = 0.1)
    hidden2       = tanh(dotW_b(hidden1, n_units = 200))
    reconstruct2  = reconstruct(hidden2.replace(hidden1,noisy_hidden1),
                            noisy_hidden1)
    err2          = cross_entropy(reconstruct2, hidden)
    learner2      = SGD(err2)

    # Top layer:

    output  = sigmoid(dotW_b(hidden2, n_units = 10))
    err     = cross_entropy(output, data_y)
    learner = SGD(err)


GPU_transform,gaussian_noise and so on are functions that have been decorated ( or classes if you want) 
that you would write using FLIT.  Reconstruct for me is a different CONTROL FLOW element. 
In this case I don't use REPEAT or BUFFER_REPEAT or the other very cool control flow elements, but you
can easily imagine writing something like

pretrained_in_parallel = weave( learner1, learner2)
results = spawn(repeat(5000,learner1),repeat(500,learner2))