> On 10.02.2018, at 20:36, Tony Garnock-Jones <tonyg at leastfixedpoint.com> wrote:
> 
> On 02/10/2018 07:02 PM, Levente Uzonyi wrote:
>> So,
>>    a perform: {#or:. #xor:. #and:} atRandom with: b
>> would just work for that imaginary interpreter if b were a Boolean.
> 
> Yes, that "interpreter" works just fine today, if b is a Boolean. It's
> the case where b is a Boolean-producing expression - such as in a "lazy"
> interpreter - that doesn't work without Fabio's proposed change.
> 
> I went and looked at the ANSI standard (draft), btw [1].
> 
> There, #xor: is specified as taking only a boolean.
> 
> So this would be an extension, potentially affecting portability, for
> what that's worth these days.
> 
> I think the performance objection has been well-refuted, and I see the
> consistency benefit as being real, but probably pretty limited, and I
> kind of don't like the potential portability implications.

I presume the main "feeling" here is parallelity:

#& takes an evaluated boolean	#and: takes an unevaluated block
#| takes an evaluated boolean	#or: takes an unevaluated block

#xor: takes an evaluated boolean but looks like #and: and #or:, 
So it seems to belong to the right side, and then we think again about 
the left side, come up with symbols, only to find that #~= and #~~ are already there.

So, just lets go all the way and document #xor: better, not making take it a block, 
maybe pointing out that #~= ist typically better fitted…

Best regards
	-Tobias