Proposal: change to qualified operator syntax
westondan at imageworks.com
Thu Jul 9 00:26:21 EDT 2009
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
> 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
More information about the Haskell-prime