[GHC] #836: rebindable if-then-else syntax

[GHC]

#836: rebindable if-then-else syntax
--------------------------------+-------------------------------------------
    Reporter:  nibro            |        Owner:         
        Type:  feature request  |       Status:  new    
    Priority:  normal           |    Milestone:         
   Component:  Compiler         |      Version:  6.4.2  
    Severity:  normal           |     Keywords:         
          Os:  Unknown          |   Difficulty:  Unknown
Architecture:  Unknown          |  
--------------------------------+-------------------------------------------
This is a request to make the syntactic if-then-else construct of Haskell
 rebindable by programmers to allow their own definition of the semantics
 of the construct.

 My main motivation for wanting this feature is that I use Haskell as a
 host for embedded languages, and these often come with their own control
 flows. So I find myself wanting to write my own definition of the if-then-
 else construct that works on terms of some other type, e.g. tests on
 values of type Exp Bool instead of Bool, and at the same time make sure
 that the user doesn't use the built-in if-then-else. Sure, I can (and do)
 call my own version if_, ifElse or something else along those lines, but
 it's sure to be a constant source of programmer errors, writing if-then-
 else instead of if_ by habit.

 Making the if-then-else construct rebindable in the same way the do
 notation is would solve the problem quite nicely, however there are some
 problems involved with doing so. The do notation is syntactic sugar for
 >>= and company so it's easy to translate it into non-prelude-qualified
 versions of functions with those names. This is not the case for if-then-
 else. But it could be, the prelude could define a function if_ (or
 whatever) that the if-then-else construct is made to be sugar for, and
 thus also amenable to rebinding by not prelude-qualifying.

 There are problems with this approach however.
 First of all, programs that import names from the Prelude explicitly would
 no longer be able to use if-then-else unless they also added 'cond' to
 that input list (or redefined it of course). This shouldn't really be a
 problem, since the rebindable syntax is turned on by adding some flag
 anyway, and if you add that flag you know you're no longer H98. Still,
 it's going to break a lot of existing programs.
 The second problem is that it would require the addition of the cond
 function to the Prelude. This will probably not break too many existing
 programs, but still it is a more serious problem since it will have effect
 even without any flags to GHC. Or is it possible to govern the contents of
 the Prelude based on flags?

 Also, is cond the best name for the suggested function? If we don't expect
 anyone to really use it without the sugar, we could name it whatever weird
 thing so as to break as few existing programs as possible. It would make
 explicit import a bit more akward though. However, I suspect that if this
 function did exist in the Prelude, people would start using it a lot.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/836>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler