<div dir="ltr"><div>On Fri, Jul 12, 2013 at 12:56 PM, Ian Lynagh <span dir="ltr"><<a href="mailto:ian@well-typed.com" target="_blank">ian@well-typed.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">From 7.8, the plan is for [dynamically-linked ghc] to be the default on platforms that</span><br>
</div>
support it.<br>
<div class="im"><span style="color:rgb(34,34,34)"></span></div></blockquote><div>snip <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">The plan is/was for this to be the only way to support GHCi, but see the</span><br></div>
discussion on <a href="http://ghc.haskell.org/trac/ghc/ticket/8039" target="_blank">http://ghc.haskell.org/trac/ghc/ticket/8039</a></blockquote><div><br></div>Thanks, Ian; very helpful. I also just read through <a href="http://ghc.haskell.org/trac/ghc/ticket/3658">http://ghc.haskell.org/trac/ghc/ticket/3658</a> — I had incorrectly assumed the DynamicByDefault page subsumed it. That helped me understand people's concerns a lot better. Here's my updated status.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_quote">I'm deciding between</div><div class="gmail_quote"><br></div><div class="gmail_quote"> * Solution 1 — using the rts/Globals.c mechanism for `FastString.string_table`, or</div>
<div class="gmail_quote"><br></div><div class="gmail_quote"> * Solution 2 — requiring a dynamically-linked ghc to (safely) use plugins that involve FastStrings.</div><div class="gmail_quote"><br></div><div class="gmail_quote">
I prefer Solution 1, because</div><div class="gmail_quote"><br></div><div class="gmail_quote"> * it handles any number of instances of libHSghc in a process, *regardless of how they got there*, and</div><div class="gmail_quote">
<br></div><div class="gmail_quote"> * it puts no constraints on the rest of the user's installation — use whatever kind of ghc you like.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I have one remaining concern: in the eventuality in which ghci becomes its own dynamically-linked binary and ghc remains statically-linked, then my patch will be the only remaining use of the `rts/Globals.c` mechanism. (For the record, that mechanism is vastly simpler than the RTS linker…)</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">We can cross that bridge if/when we come to it, though.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I'm planning to push Solution 1 to HEAD this weekend, unless someone shouts at me politely.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Thanks, everyone, for your input.</div></div></div></div>