I was just browsing the fandoc for Bool, Int etc. and found myself struggling to see the meat of each class.

The main problem was the number of operator overload methods. Because these are shown as simple ordinary slots, they are intermingled with other slots alphabetically. Most of the time I'd suggest that you don't want to see the operator overload methods.

My suggestion would be to group the fandoc in two parts - non-operator-overload slots, followed by operator-overload slots.

Further to this would be a broader concern about the sheer number of method names that are effectively reserved by the current approach. While some are not that likely to be needed (lshift), others might well be (star). Given the specific purpose of these methods is it worth changing the naming convention? Maybe something more like:

operator-star() {...}
operator-lshift() {...}

Regarding the organization that might be solved with a bit of JavaScript magic (I'm sure Andy can come up with something cool).

It doesn't hurt anything if you use a operator method name - that is why we picked symbol names versus mathematical names. For example "|" is pipe, not or. And InStream actually implements a pipe method. So you could actually write code like this:

file.in | Sys.out

Which I think reads fine as "pipe file.in to Sys.out". Although I personally would write that as:

file.in.pipe(Sys.out)

But I don't think it hurts anything - we aren't really reserving them, just saying that those names can be used as operators if you so choose. So I like having the operators be simple symbol names. Groovy does something similar but choose the mathematical names.

Hmmm. I like and support operator overloading, but such unlimited things as

file.in | Sys.out

cross the line of what I think is acceptable.

Now, I have no problem with allowing users to define such an operator themselves. I just don't think it should be automatic based on a method name - that way leads to the dark side of operator overloading IMO.

I think you should have to think and take specific action to make a method an operator. Two options:

operator-pipe() {...}
operator pipe() {...}

The former is just a less likely slot name. The latter is a new keyword that authorises the method to act as the matching operator (you might be able to use facets).

I could be convinced - but I'd want to hear a lot more opinions first.

If all operator names were only nouns this wouldn't be a problem, as you normally choose verbs as method names. But pipe for example is not only a noun but a verb as well ...