| Where is there documentation for rebindable syntax for monads with class
| constraints:
|
| (>>=) :: (Foo m, Baz a) => m a -> (a -> m b) -> m b
|
| http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/9447/match=syntax
|
| The users guide seems to disallow such type signatures:
|
| http://haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax
I don’t think it’s in 6.4.   Here’s
the documentation from the HEAD. 
Simon
GHC allows most kinds of built-in
syntax to be rebound by the user, to facilitate replacing the Prelude with a home-grown version,
for example.
You may want to define your own
numeric class hierarchy. It completely defeats that purpose if the literal
"1" means "Prelude.fromInteger 1", which is what the
Haskell Report specifies. So the -fno-implicit-prelude flag causes the following
pieces of built-in syntax to refer to whatever is in scope, not the
Prelude versions: 
·        
An integer literal 368 means "fromInteger
(368::Integer)", rather than "Prelude.fromInteger
(368::Integer)". 
·        
Fractional literals are handed in just the same way,
except that the translation is fromRational
(3.68::Rational). 
·        
The equality test in an overloaded numeric pattern
uses whatever (==) is in scope. 
·        
The subtraction operation, and the
greater-than-or-equal test, in n+k patterns use whatever (-) and (>=) are in scope. 
·        
Negation (e.g. "- (f x)") means "negate (f x)", both in numeric
patterns, and expressions. 
·        
"Do" notation is translated using whatever
functions (>>=), (>>), and fail, are in scope (not the
Prelude versions). List comprehensions, mdo (Section 7.3.3,
“The recursive do-notation ”), and parallel array
comprehensions, are unaffected. 
·        
Arrow notation (see Section 7.7, “Arrow notation
”) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. But
unlike the other constructs, the types of these functions must match the Prelude
types very closely. Details are in flux; if you want to use this, ask! 
In all cases (apart from arrow
notation), the static semantics should be that of the desugared form, even if
that is a little unexpected. For emample, the static semantics of the literal 368 is exactly that of fromInteger
(368::Integer); it's fine for fromInteger to have any of the types: 
fromInteger :: Integer -> IntegerfromInteger :: forall a. Foo a => Integer -> afromInteger :: Num a => a -> IntegerfromInteger :: Integer -> Bool -> BoolBe warned: this is an experimental
facility, with fewer checks than usual. Use -dcore-lint to typecheck the desugared
program. If Core Lint is happy you should be all right.