#4177: GHCi should allow custom definition of print for implicit output
---------------------------------+------------------------------------------
    Reporter:  ezyang            |       Owner:              
        Type:  feature request   |      Status:  new         
    Priority:  normal            |   Component:  GHCi        
     Version:  6.10.4            |    Keywords:              
          Os:  Unknown/Multiple  |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 Right now, a value of type a desugars to:

 {{{
 let it = expr
 print it
 }}}

 Where print is actually an identifier referencing System.IO.print. This
 makes it a tad difficult for users to overload the behavior of print for
 their own nefarious (debugging) purposes.

 I propose that we allow some way of overriding the print used for printing
 statements.  I think there are few ways we could do this:

  * We could look in the user bindings and check to see if there is print
 defined, and then use that instead. This would truly make this “just an
 extension to the Prelude”, but if there are conflicting definitions of
 print the user may not appreciate the breakage (though they'd be able to
 just let print = ... to resolve the ambiguity).

  * We could look in the user bindings and check to see if there is some
 magic variable corresponding to print defined, and use that instead.

  * We could add a command that adds a special binding for print and
 references that instead (default being System.IO.Print).

 I have a vague idea how you might implement the first two by editing
 ./compiler/typecheck/TcRnDriver.lhs, although I don't know how one would
 make the local binding information available at that location. I have no
 idea how to implement the latter.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4177>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to