Alright, I did a little bit of preliminary work, and I created a branch [1] which might be what you're looking for. If you compile the package with the "debian" and "create" flags, it'll use unsafePerformIO to read the public suffix list from the file that you've listed. Do you want to do me a favor and take a look at the code to see if it really does solve the problem?
I used these commands to build it: $ runhaskell Setup.lhs configure --user --enable-tests -f "debian create" $ runhaskell Setup.lhs build $ runhaskell Setup.lhs test Thanks, Myles C. Maxfield [1] https://github.com/litherum/publicsuffixlist/tree/debian On Sun, Mar 3, 2013 at 2:56 PM, Joachim Breitner <[email protected]> wrote: > Hi, > > mostly in order to get this discussion going again ([1] is just not > green enough), I’ll add my 2¢. > > Given that this is volatile data, I’d also prefer it to be shipped in > the general purpose publicsuffix package, and used, at runtime, by the > Haskell publicsuffixlist Haskell library. (If there is a performance > overhead due to parsing the list, we could still try to get a > lookup-optimized binary-packed representation in the publicsuffixlist > package, but let’s not worry about premature optimization). > > My suggestion would be, if that would be ok for everyone (mainly Myles): > The publicsuffixlist library gets a cabal flag that enables a dependency > on publicsuffixlistcreate and modifies (via CPP) > Network.PublicSuffixList.DataStructure.datastructure to read the data > from the file at /usr/share/publicsuffix/effective_tld_names.dat via > unsafePerformIO. (It feels a little dirty, but really, why should > including static data in a .so file be better than in a .txt file). > > Is that a way forward? > > Greetings, > Joachim > > [1] > https://buildd.debian.org/status/[email protected]&suite=experimental&compact=compact&a=amd64 > > -- > Joachim "nomeata" Breitner > Debian Developer > [email protected] | ICQ# 74513189 | GPG-Keyid: 4743206C > JID: [email protected] | http://people.debian.org/~nomeata > >
