>From: Lex Spoon [mailto:lex at cc.gatech.edu]
>>The #in: family actually sounds pretty good to me.  (I hadn't realized
>>#in: was in the system; I do like the idea!).  I like #inIfNotNil:
>  >better than #ifNotNilIn:, though -- the first sounds more gramatical.

I think that I prefer  IfNotNilDo: or IfNotNilIn: versions better 
than "IfNotNilBeValueFor", for the reasons already expressed: that we 
don't want to draw attention to the block itself, but instead to its 
action, or its value.

By analogy with monadic functional programming, do: emphasizes the 
action, and in: the value.  In Squeak, they are indistinguishable. 
So I vote for either.

I sort of agree that do: has an accepted Smalltalk-specific meaning 
of expecting a unary block that will be repeatedly applied to 
arguments emitted by the receiver.  But, how many times is 
"repeatedly"?  It depends on the values that one can get out of the 
receiver; it might be 100, it might be zero, and yes, it just might 
be one.  In this case, it happens to be one.

While we are beating on this, I'm going to object to the implementation of in:

	in: aBlock
		"Evaluate the given block with the receiver as its argument."

		(aBlock isKindOf: BlockContext) ifFalse: [self error: 
'expecting a block'].
		^ aBlock value: self

Do you agree that the class test leaves a bad smell?  If a test is 
needed to warn the unwary that points, say are not good arguments, 
then (IMnotsoHO) the "right" condition is:

	(aBlock repondsTo: #value:)

because that is the correct precondition for the next statement.  (I 
can easily make objects that respond to value: that are not 
subclasses of BlockContext.) Indeed, I sometimes write tests like 
that, for example when writing methods that take blocks as arguments 
and then store them away for later use.  My justification is that I 
would rather that an inappropriate argument is detected sooner than 
later.

However, in this case, the inappropriate argument will be detected 
immediately, on execution of the very next statement.  So why bother 
wasting those 4 microseconds ... we may need them someday :-)

	Andrew