I looked at Actions, and liked what I saw. I've seen and done things like that before. My main complaint is that the method should be #value and #value:, not #evaluate and #evaluate: A block is a built-in Action, and it already defines a protocol, so we should use it.

One of the interesting things is that Actions define both #value and #evaluate. So, you can use an Action instead of a block, but you can't use a block instead of an Action. Why? A block is just a built-in Action. Now, the fileIn defines #evaluate and #evaluate: for blocks, but that does not passify me! We should not proliferate protocols, and #value and #value: are well defined and short. They are not particular logical, but that is not so important for the most common messages. #at:put: is not particularly logical, either.

It is a mistake to put #evaluate and #evaluate: in Object. ParcPlace did this with #value and #value: for awhile, and the problem is that you lose useful information because errors don't get caught right away but the system keeps on running for awhile before finally noticing some error. It is so easy to convert an object into an Action (just send #asAction to it) that you don't need these helper methods in Object. Further, using #asAction provides helpful information to the reader that an object is going to be used as an action, so it gives hints that can prevent the reader from having to keep on reading.

BlockContext should define asAction to return self, not to make a new action that returns itself. A block is just a built-in action.

(I'm hoping that if I say it enough, people will believe me!)

Blocks should also have , defined to be the same as in Action.

There is no reason for ActionSecuence, and its comment should be moved to ActionComposite. I like CompositeAction better as a name, by the way. It follows Kent Beck's pattern for naming subclasses, which I think describes the way most experienced Smalltalkers do it.

-Ralph