Likewise scouts — I regard it as an artifact of the code organization that bottom-up scouts don’t have objects attached when they’re posted. In my way of thinking, to determine an action, I always select a unit first, then determine what kinds of action it might want taken. I think this should work — it should be equivalent, really, just organized differently.

But I’m happy to see your intuition is going in the same direction as mine, with your action fringe. That’s heartening.

–ab

These codelets with zero objetcs, what do they do? Aren’t they all for “system maintenance”? (that’s my case at least, so I’m wondering if my system is lacking in some important flexibility).

There are chunks, objects which include others, and relations, things that obtain some objects and create new ones from the original. If a specific relation wants to change an object X inside a chunk C and an object Y outside of it, we will have a (C,Y)-coderack. Neither the chunk nor the 2nd object can be altered without entering this particular coderack (and its thread).

You point out an interesting problem: perhaps 1000 coderacks with only two codelets might arise? Well, that is true.. it could be. But think about this: current processors are already at 45 nanometers… they’re getting to the limits, which makes me feel that soon, maybe 5 years, we’ll have 64 processors on a regular 1500 dollar noteboook.

And if that isn’t enough, just google up “GPGPU” and “stream processing”.

Seqsee already does what you mention in Paragraph 3 of your comment. I call this the action fringe of the object (where object is a number, group, bond, or category, but that can be extended). {See “get-actions” in lib/SThoughts/SObject.pm, for actions on groups and on numbers. The code needs clean up, but might be somewhat intellegible.} This is over and beyond the Coderack, which is still needed. Not all actions are related to individual objects. Some are related to none, others to more than one, and thus you need a Coderack for those things.

Here’s how I see it. The Coderack is simply a list of possible things to try on a more or less random basis. I think it’s far cleaner to come up with action pressures directly. For instance, if we have a scan group a b c, then there is naturally some pressure to try to extend it to a b c d. That pressure ceases to exist when the group is gone, and it’s higher if the group is salient.

But salience is just a matter of interest, or attention, or whatever you want to call it. Actually, I think a cleaner way to organize the activity of the entire model is simply to choose a salient object at random, then ask it, “what pressures do you feel,” then choose a codelet at random based on that pressure. There is no rack, per se.

In situations where there are multiple codelets to break a given process up into discrete pieces (e.g. scout-assess-build), this “momentum” can, and should. be represented as a state of the object itself. In a scout-assess-build model, the scout codelet proposes an object (say), by which we can mean, “creates a Workspace object with state ‘proposed’.” Now that object actually exists already, but is special in that it can’t be used as a component unit in other objects. (This bit’s hand-wavy.) But it can still have a high salience or urgency or attention, and when we ask it, “what do you want to do today,” it can reply, “get built.” See?

In this model there is no actual Coderack, meaning that the massive parallelism can take care of itself.

This model of codelets is my next task for Copycopycat. Wish me luck.

If there are too many Coderacks, so many, in fact, that the expected population of each is less than 2 codelets, we may not have gained much. you’d need a happy medium, somewhat between 1 and too many.

Again, I do not disagree, just trying to understand your proposal better.

–Ab