<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Perhaps there may be useful ideas in <a href="https://draugus.github.io/pdf/Software%20Design%20for%20Flexibility%20-%20Chris%20Hanson.pdf">https://draugus.github.io/pdf/Software%20Design%20for%20Flexibility%20-%20Chris%20Hanson.pdf</a> .<br><br><div dir="ltr">Howard</div><div dir="ltr"><br><blockquote type="cite">On Oct 20, 2023, at 1:23 PM, Ben Gamari <ben@well-typed.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>Ben Gamari <ben@well-typed.com> writes:</span><br><span></span><br><blockquote type="cite"><span>...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span># Phase 2: Template Haskell</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The above story is made considerably messier by `template-haskell`.</span><br></blockquote><blockquote type="cite"><span>...</span><br></blockquote><span></span><br><span>One further clarification as I fear this may be unclear:</span><br><span></span><br><span>Phase 2 does *not* allow multiple versions of `template-haskell` to</span><br><span>be used with a single GHC. That is, each GHC version will have precisely</span><br><span>one corresponding `template-haskell` version; consequently, programs</span><br><span>using TemplateHaskell's combinator's will still need to adapt to new</span><br><span>`template-haskell` releases when moving to a new GHC.</span><br><span></span><br><span>Phase 3 describes how we could eliminate this need by allowing multiple</span><br><span>`template-haskell` versions to be used with a single GHC release.</span><br><span>_______________________________________________</span><br><span>ghc-devs mailing list</span><br><span>ghc-devs@haskell.org</span><br><span>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</span><br></div></blockquote></body></html>