<div dir="ltr"><div dir="ltr"><div><div dir="auto">On the flip side we could just add data Addr ... to foreign .ptr or a child / sibling module like System.Mem.Address and defer the associated cleanup</div></div><div dir="auto"><br></div><div>I kinda like the idea of System.Mem.Address, </div><div><br></div><div>i put a strawman change set on phab <a href="https://phabricator.haskell.org/D5268">https://phabricator.haskell.org/D5268</a></div></div></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 12:23 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">granted most of the Addr# sites dont matter<div><br></div><div>a related issue is what operations WOULD be added for Addr? </div><div><br></div><div>maybe just memcopy friends plus address arithmetic, plus a mapper from/to Ptr a?</div><div><br></div><div>does it simply become a byte size step sibling to Ptr a that put in Foreign.Ptr?</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 12:18 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="auto">Before we bike shed these details, let’s evaluate / document the pieces of base that should also be moved to using Addr.  Though that module where</div></div><div dir="auto"><br></div><div dir="auto">1) What exported types / data definitions / functions will have changes ?</div><div dir="auto"><br></div><div dir="auto">2) what internal apis need to change?</div><div dir="auto"><br></div><div>as a lower bound estimate of work surface area, i grepped for "Ptr ()"  and "Addr#" in a fresh recursive clone of ghc at commit 503514b94f8dc7bd9eab5392206649aee45f140b,</div><div>limiting my search to .hs and .hsc files</div><div><br></div><div>THERES A LOT of uses of Ptr (), and its siblings StablePtr () and RemotePtr () ,   The latter two dont have a simple Addr# underneath, </div><div><br></div><div>heres the list of files that match that search   rg 'Ptr \(\)' --type haskell -c</div><div><br></div><div><div>ghc/GHCi/Leak.hs:1</div><div>utils/hsc2hs/Main.hs:1</div><div>utils/runghc/Main.hs:1</div><div>compiler/ghci/GHCi.hs:4</div><div>compiler/ghci/ByteCodeLink.hs:3</div><div>compiler/ghci/ByteCodeGen.hs:4</div><div>compiler/ghci/ByteCodeTypes.hs:1</div><div>compiler/ghci/ByteCodeAsm.hs:2</div><div>compiler/main/HscTypes.hs:1</div><div>libraries/ghci/GHCi/ObjLink.hs:3</div><div>libraries/ghci/GHCi/StaticPtrTable.hs:1</div><div>libraries/ghci/GHCi/ResolvedBCO.hs:1</div><div>libraries/ghci/GHCi/RemoteTypes.hs:2</div><div>libraries/ghci/GHCi/Run.hs:2</div><div>libraries/ghci/GHCi/Message.hs:5</div><div>libraries/base/GHC/Stable.hs:2</div><div>libraries/base/GHC/StaticPtr.hs:1</div><div>libraries/base/GHC/Generics.hs:2</div><div>libraries/base/GHC/TopHandler.hs:1</div><div>libraries/base/GHC/Windows.hs:1</div><div>libraries/base/tests/dynamic002.hs:2</div><div>utils/haddock/haddock-api/src/Haddock.hs:1</div><div>libraries/array/Data/Array/IO.hs:2</div><div>libraries/base/Foreign/Marshal/Pool.hs:1</div><div>libraries/bytestring/Data/ByteString/Builder/Extra.hs:1</div><div>libraries/base/GHC/IO/Handle/Text.hs:1</div><div>testsuite/tests/rts/T7160.hs:1</div><div>testsuite/tests/rts/overflow3.hs:1</div><div>testsuite/tests/rts/overflow2.hs:1</div><div>testsuite/tests/rts/T5250.hs:1</div><div>testsuite/tests/rts/T10296b.hs:2</div><div>testsuite/tests/th/T3319.hs:1</div><div>testsuite/tests/th/TH_foreignInterruptible.hs:1</div><div>testsuite/tests/th/TH_foreignCallingConventions.hs:1</div><div>libraries/Cabal/cabal-install/Distribution/Client/Win32SelfUpgrade.hs:1</div><div>libraries/Cabal/Cabal/Distribution/Simple/InstallDirs.hs:2</div><div>testsuite/tests/llvm/should_compile/T5486.hs:2</div><div>testsuite/tests/codeGen/should_run/cgrun070.hs:5</div><div>testsuite/tests/codeGen/should_run/cgrun026.hs:3</div><div>testsuite/tests/primops/should_run/T4442.hs:1</div><div>testsuite/tests/ffi/should_fail/T7243.hs:1</div><div>testsuite/tests/ffi/should_fail/T3066.hs:1</div><div>testsuite/tests/ffi/should_compile/cc009.hs:1</div><div>testsuite/tests/ffi/should_run/ffi021.hs:1</div><div>testsuite/tests/typecheck/should_compile/T7408.hs:1</div><div>libraries/Cabal/cabal-install/Distribution/Client/Compat/ExecutablePath.hs:1</div><div>libraries/Cabal/Cabal/Distribution/Simple/Build/PathsModule.hs:1</div><div>libraries/time/lib/Data/Time/Clock/Internal/CTimeval.hs:1</div><div>testsuite/tests/rename/should_compile/T3103/Foreign/Ptr.hs:1</div></div><div dir="auto"><br></div><div>likewise the locations where Addr# comes up are as follows (some of these perhaps should be an Addr? )</div><div><br></div><div><div>$ rg 'Addr#' --type haskell -c</div><div>utils/genprimopcode/Main.hs:2</div><div>ghc/GHCi/Leak.hs:2</div><div>compiler/cmm/CmmMachOp.hs:1</div><div>compiler/cmm/CmmUtils.hs:1</div><div>compiler/specialise/Rules.hs:2</div><div>compiler/basicTypes/MkId.hs:2</div><div>compiler/basicTypes/Literal.hs:6</div><div>compiler/basicTypes/Unique.hs:2</div><div>compiler/utils/StringBuffer.hs:1</div><div>compiler/utils/FastString.hs:4</div><div>compiler/utils/Encoding.hs:9</div><div>compiler/codeGen/StgCmmPrim.hs:3</div><div>compiler/coreSyn/MkCore.hs:5</div><div>compiler/coreSyn/CoreLint.hs:2</div><div>compiler/coreSyn/CoreSyn.hs:4</div><div>compiler/coreSyn/CorePrep.hs:1</div><div>compiler/stranal/WwLib.hs:1</div><div>compiler/simplCore/CSE.hs:1</div><div>compiler/simplCore/Simplify.hs:2</div><div>compiler/deSugar/DsExpr.hs:1</div><div>compiler/typecheck/TcGenDeriv.hs:5</div><div>compiler/prelude/ForeignCall.hs:1</div><div>compiler/prelude/PrelNames.hs:1</div><div>compiler/prelude/TysPrim.hs:1</div><div>compiler/ghci/ByteCodeGen.hs:8</div><div>libraries/bytestring/tests/revcomp.hs:1</div><div>libraries/bytestring/Data/ByteString.hs:5</div><div>libraries/ghc-heap/tests/heap_all.hs:1</div><div>libraries/ghc-prim/GHC/CString.hs:17</div><div>libraries/ghc-prim/GHC/Classes.hs:1</div><div>libraries/ghc-prim/GHC/Types.hs:3</div><div>libraries/ghci/GHCi/BinaryArray.hs:1</div><div>libraries/ghci/GHCi/CreateBCO.hs:5</div><div>libraries/base/codepages/MakeTable.hs:1</div><div>libraries/base/GHC/Ptr.hs:8</div><div>libraries/base/GHC/Generics.hs:5</div><div>libraries/base/GHC/Storable.hs:32</div><div>libraries/base/GHC/ForeignPtr.hs:6</div><div>libraries/base/Foreign/Ptr.hs:2</div><div>libraries/bytestring/Data/ByteString/Unsafe.hs:6</div><div>libraries/bytestring/Data/ByteString/Internal.hs:7</div><div>libraries/ghc-heap/GHC/Exts/Heap.hs:1</div><div>libraries/text/Data/Text/Show.hs:2</div><div>libraries/text/Data/Text/Lazy.hs:2</div><div>libraries/containers/Data/IntSet/Internal.hs:4</div><div>libraries/ghc-compact/GHC/Compact/Serialized.hs:11</div><div>libraries/base/GHC/IO/Exception.hs:1</div><div>libraries/base/Data/Typeable/Internal.hs:3</div><div>libraries/base/Control/Exception/Base.hs:1</div><div>utils/haddock/html-test/src/Ticket112.hs:1</div><div>testsuite/tests/rts/T8242.hs:19</div><div>testsuite/tests/ghci.debugger/HappyTest.hs:3</div><div>testsuite/tests/arityanal/Main.hs:3</div><div>testsuite/tests/th/TH_StringPrimL.hs:2</div><div>testsuite/tests/th/T1830_3a.hs:2</div><div>libraries/template-haskell/Language/Haskell/TH/Syntax.hs:1</div><div>libraries/bytestring/Data/ByteString/Short/Internal.hs:16</div><div>libraries/integer-gmp/src/GHC/Integer/Type.hs:11</div><div>libraries/base/GHC/IO/Encoding/CodePage.hs:3</div><div>libraries/Cabal/Cabal/Distribution/Parsec/Lexer.hs:9</div><div>testsuite/tests/generics/GEq/GEq1A.hs:1</div><div>testsuite/tests/generics/GEq/GEq1.hs:2</div><div>testsuite/tests/codeGen/should_compile/cg008.hs:1</div><div>testsuite/tests/codeGen/should_run/cgrun070.hs:4</div><div>testsuite/tests/codeGen/should_run/T9577.hs:1</div><div>testsuite/tests/codeGen/should_run/cgrun066.hs:1</div><div>testsuite/tests/codeGen/should_run/cgrun026.hs:2</div><div>testsuite/tests/codeGen/should_run/T2080.hs:2</div><div>testsuite/tests/codeGen/should_run/T9577_A.hs:1</div><div>testsuite/tests/primops/should_run/T4442.hs:4</div><div>testsuite/tests/simplCore/should_compile/T13367.hs:1</div><div>testsuite/tests/simplCore/should_compile/T13155.hs:2</div><div>testsuite/tests/simplCore/should_compile/T14779a.hs:1</div><div>testsuite/tests/simplCore/should_compile/T14779b.hs:2</div><div>testsuite/tests/simplCore/should_compile/spec001.hs:1</div><div>testsuite/tests/lib/integer/integerGmpInternals.hs:9</div><div>testsuite/tests/perf/compiler/T14683.hs:3</div><div>testsuite/tests/ghci/should_run/T2589.hs:1</div><div>libraries/integer-gmp/src/GHC/Integer/GMP/Internals.hs:7</div><div>libraries/text/Data/Text/Internal/Fusion/Common.hs:3</div><div>libraries/base/GHC/IO/Encoding/CodePage/Table.hs:1</div></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div></div></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 11:01 AM Daniel Cartwright <<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Also, where in base should Addr go?</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 10:15 AM Daniel Cartwright <<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I would, yeah. Should the next version of `primitive` just re-export `Addr` from base in `Data.Primitive.Addr`?</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 10:14 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Daniel or David, would either of you be interested/willing to do the legwork on this patch wise (subject to sanity checking whats the impact surface area?)</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 12:04 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="auto">Cool. What apis in base should move to use Addr from fake pointer ? Cause just adding it in isolation seems lame! </div></div><div dir="auto"><br></div><div dir="auto">I guess I’m just trying to say “what would the impact on base, if every fake Ptr was moved to be Addr?” Because it’s not something which should be done by halves. </div></div><div dir="auto"><br></div><div dir="auto">1) what apis would be changed?</div><div dir="auto"><br></div><div dir="auto">2) what internal things would be changed albeit not Api visible </div><div dir="auto"><br></div><div dir="auto">3). Address arithmetic for Addr is very different from addres arithmetic on larger than word8 size storable values, is there anything which would move representations where the change to byte indexed would change the calculations ?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">If we can layout what the impact / scope of changes needed for these and other considerations, I guess I’d be all for it. Assuming there’s the corresponding interest in executing changes. (I just have this worry in my head that it might be one of those icebergs.. like the split base effort )</div><div dir="auto"><br></div><div dir="auto"><br></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 11:33 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018, 11:28 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">Pretending we’re talking about this with storable as our example semantics : </div><div dir="auto"><br></div><div dir="auto">Ptr Void </div></div><div dir="auto">Corresponds to a memory address you don’t want to read or write to.</div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is not so easy to think about (there's not much utility in such a type). Perhaps Ptr Void is a reasonable type for pointers known to be null or outside the address space, but I'm not sure.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br></div><div dir="auto">Ptr () corresponds to a memory location that’s pretty boring to read / write to</div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes! In other words, it's *not* what people should be using for a pointer to an arbitrary non-Haskell address. That's precisely what Addr is for.</div></div><div dir="auto"><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 11:22 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">... when is a valid pointer not going to point at byte addressable memory on memory architectures ghc can support or target? </div></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <<a href="mailto:chessai1996@gmail.com" rel="noreferrer" target="_blank">chessai1996@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <<a href="mailto:chessai1996@gmail.com" rel="noreferrer" target="_blank">chessai1996@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">yes, only the type and its instances should be moved as far as i'm aware.<div><br></div><div>Also, it's more than just base.</div><div><br></div><div>this Ptr is a lie: <a href="https://hackage.haskell.org/package/ghc-compact-0.1.0.0/docs/GHC-Compact-Serialized.html#t:SerializedCompact" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/ghc-compact-0.1.0.0/docs/GHC-Compact-Serialized.html#t:SerializedCompact</a></div><div>these Ptrs are lies: <a href="https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-IO-Handle.html" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-IO-Handle.html</a></div><div>in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie</div><div><br></div><div>These are just off the top of my head, there are more</div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) </div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 6:19 PM David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer" target="_blank">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">We shouldn't really need to move anything into base except Addr and its base instances.</div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 25, 2018 5:59 PM, "Carter Schonwald" <<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br type="attribution"><blockquote class="m_607219586383326759m_4108104222861347235m_-577881444633252207m_-1735462856945289620m_4930956109623724567m_-7366948936317287234m_8958011854641219034m_9174259078894469421m_5046327368521796560m_-1898907845613092665m_5831305755901727906m_-2348709952183251237m_7782168492079007908m_1830870421978878534m_7935052445482958367m_4250738866633960983quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. </div></div><div dir="auto"><br></div><div dir="auto">Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. </div><div class="m_607219586383326759m_4108104222861347235m_-577881444633252207m_-1735462856945289620m_4930956109623724567m_-7366948936317287234m_8958011854641219034m_9174259078894469421m_5046327368521796560m_-1898907845613092665m_5831305755901727906m_-2348709952183251237m_7782168492079007908m_1830870421978878534m_7935052445482958367m_4250738866633960983elided-text"><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <<a href="mailto:andrew.thaddeus@gmail.com" rel="noreferrer noreferrer" target="_blank">andrew.thaddeus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <<a href="mailto:chessai1996@gmail.com" rel="noreferrer noreferrer" target="_blank">chessai1996@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.</div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_607219586383326759m_4108104222861347235m_-577881444633252207m_-1735462856945289620m_4930956109623724567m_-7366948936317287234m_8958011854641219034m_9174259078894469421m_5046327368521796560m_-1898907845613092665m_5831305755901727906m_-2348709952183251237m_7782168492079007908m_1830870421978878534m_7935052445482958367m_4250738866633960983m_-301628934586710594m_-5237605456241773259gmail_signature" data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</div></blockquote></div><br></div>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div></div>
</blockquote></div></div>
</div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>