Proposal: change to qualified operator syntax

[Dan Weston]

kahl at cas.mcmaster.ca wrote:

> which in my opinion only asks for extension of the backquote symtax to
> arbitrary epressions, like
> 
>   `zipWith (+)`
> 
> . I frequently run into situations where that would be extremely useful.

What is the fixity and associativity of this infix "operator"? For that 
matter, in a let expression

   let (+++++) = (+) in 5 * 2 +++++ 3 - 2

what is the fixity and associativity of (+++++)? Does it inherit these 
from (+) by virtue of let? If not, then the obvious local workaround of

   let (>>=) = Prelude.(>>=) in ....  >>=  ...

would not be a drop-in lexical substitution.

> The QualifiedOperators page also says:
> 
>  | You might argue that it is inconsistent to allow `(+)` but not allow
>  | (`plus`), but the justification is simply that (..) and `..` are not
>  | dual in this design.
> 
> I would indeed argue that they should be dual.

So lexically, given an opening `, is the closing ` the first one 
enclosing balanced parentheses?

   2 `(`(`(`(+)`)`)`)` 3 == 5

> Back to the original argument:
> 
>  > Prelude.>>= just doesn't look like an infix operator.
> 
> I think that
> 
>   `Prelude.(>>=)`
> 
> doesn't really look like an infix operator either.

Wouldn't it be much cleaner to outlaw all qualified operators in lieu of 
a top-level import:

   import Prelude((>>=) as (>>>=), fst as myFst)

leaving fixity and associativity of operators intact unless overridden:

   import Prelude((+) as (++++))  -- assumes infixl 6 as in Prelude
   infixr 3 ++++                  -- but for this file I will change it

Dan