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