All:

One snag seem to happen here:

Scanner>>scanToken

	[(tokenType _ typeTable at: hereChar asciiValue) == #xDelimiter]
		whileTrue: [self step].  "Skip delimiters fast, there almost always is
one."
	mark _ source position - 1.
	(tokenType at: 1) = $x "x as first letter"
		ifTrue: [self perform: tokenType "means perform to compute token &
type"]
		ifFalse: [token _ self step asSymbol "else just unique the first
char"].
	^token

The token type of | is #verticalBar, which does not begin with x, and it
does not combine with other symbols to form a token. I am sure that
there are good reasons for this. You would like |[, |(, )|, ]|, and ||
(and maybe others) to remain unambiguous. 

I could fiddle with it to have it recognize |> and <| as tokens (best to
do without ||, I think), but I do not really know what is best.

Any help appreciated. :-)

Many thanks,

Bill

Bill Spight wrote:
> 
> All:
> 
> I am implementing Combinatorial Games. (Conway numbers and
> infinitesimals are combinatorial games, FYI.) Combinatorial games are
> partially ordered, and may be confused with each other (neither greater
> than, less than, or equal to). G || H means that G is confused with H, G
> |> H means that G is greater than or confused with H, and G <| H means
> that G is less than or confused with H.
> 
> The trouble is that, when I try to make any of those an operator, I seem
> to run into the use of || to delimit local variables. I get an error
> message, "Argument name expected ->". The loss of || is not so bad, as
> <> is an alternative. But it would be nice to use <| and |>, and I do
> not see a necessary conflict with other usage.
> 
> Any help much appreciated. :-)
> 
> Thanks,
> 
> Bill