[GHC] #9795: Debug.Trace.trace is too strict

[GHC]

#9795: Debug.Trace.trace is too strict
-------------------------------------+-------------------------------------
        Reporter:  jcpetruzza        |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:  7.12.1
       Component:  libraries/base    |                 Version:  7.8.3
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by thomie):

 Replying to [comment:14 jcpetruzza]:
 > Perhaps there are very good reasons to keep trace strict, but I'm not
 aware of them...

 I see 3 reasons:
 * For Windows gui applications, the trace message is printed to something
 called the debug console (if it is enabled). It prepends the message with
 the current time or something. I think the way it works is, we have to
 collect the full message first, and then make some windows api call to
 print the message at once. Different messages should not get interleaved,
 and you don't want to split a single message over multiple lines (one for
 each character). So on Windows we can not simply make your proposed
 change. It would be confusing if `trace` were only lazy in the message on
 other platforms, but still strict on Windows.

 * Debug.Trace also exports `traceEvent` and `traceMarker`, which emit a
 message to the GHC eventlog. Again, this is a strict operation. It would
 be confusing if those functions had different laziness semantics from
 `trace`. This could be solved with documentation.

 * As Edward said in comment:3, it would be a user visible change, which is
 better handled on the libraries list.

 Perhaps make a library proposal to add a new `trace` like function to
 Debug.Trace, that is lazy in the message? The name would be the hardest
 part. `traceStderr` could be an option.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9795#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler