On Dec 14, 2011, at 8:38 AM, Thomas Schilling wrote:

On 12 December 2011 22:39, Antoine Latter <aslatter@gmail.com> wrote:
But now they look as if they are of equal importance with the other
class methods, which is not really true.

Maybe, but something like this is best fixed by improving
documentation, not by shuffling things around and needlessly breaking
APIs. I also agree that if an Alternative instance doesn't make sense
it should be removed. The current documentation is indeed very terse
indeed. In particular it needs a section on the pitfalls that users
are likely to run into (like infinite loops).

It seems that if we go down this route, though, then what we really need is a big, bold warning at the top of the Alternative class saying something like, "Do *not* implement this class for your type unless you *really* know what you are doing, which will probably only true if you are writing a parser. If you fail to heed this advice, then many and some will almost assuredly be broken for your type, which will cause code using it to have infinite loops."