- Haskell-Cafe - Haskell.org

How to support multiple string types in Haskell?
by KwangYul Seo 15 Jul '16

15 Jul '16

Hi all, There are multiple string types in Haskell – String, lazy/strict ByteString, lazy/strict Text to name a few. So to make a string handling function maximally reusable, it needs to support multiple string types. One approach used by TagSoup library is to make a type class StringLike which represents the polymorphic string type and uses it where a String type is normally needed. For example, parseTags :: StringLike str => str -> [Tag str] Here parseTags takes a StringLike type instead of a fixed string type. Users of TagSoup can pick any of String, lazy/strict ByteString, lazy/strict Text because they are all instances of StringLike type class. It seems StringLike type class is quite generic but it is used only in the TagSoup package. This makes me wonder what is the idiomatic way to support multiple string types in Haskell. What other approaches do we have? Thanks, Kwang Yul Seo

4 3

Memory Management and Lists
by Christopher Howard 15 Jul '16

15 Jul '16

Hi, short version of the question: when elements are 'drop'ped from a list, when is the memory for those elements released? And is there some way to control that? Longer version: I have this situation where I've got a State monad carrying a Data.Matrix, and I... 1) generate in infinite list of monadic operations with (repeat mf) where mf is a monadic function. 2) 'sequence' (from Control.Monad) to get a monad containing the infinite list of all states (i.e., a list of Matrices). 3) evalState(T) to extract the list 4) extract the nth state with (head (drop (n-1))) I like this approach. However, there seems to be a memory management issue: a Matrix itself should only be, I'm guessing, somewhere around 100KB. But instead I'm maxing out the 3GB of RAM on my old T60 laptop. Maybe I'm generating list elements (Matrices) a lot faster than memory management is releasing them...? -- http://qlfiles.net To protect my privacy, please use PGP encryption. It's free and easy to use! My public key ID is 0x340EA95A (pgp.mit.edu)

10 20

efficient operations on immutable structures
by Christopher Howard 14 Jul '16

14 Jul '16

Hi again all. From some online research, I understand that operations on complex immutable structures (for example, a "setter" function a -> (Int, Int) -> Matrix -> Matrix which alters one element in the Matrix) is not necessarily inefficient in Haskell, because the (compiler? runtime?) has some means of sharing unchanged values between the input and output structure. What I am not clear on, however, is how this works, and how you ensure that this happens. Could someone perhaps elaborate, or point me to a really good read on the subject? -- http://qlfiles.net To protect my privacy, please use PGP encryption. It's free and easy to use! My public key ID is 0x340EA95A (pgp.mit.edu)

3 2

Is the #functional programming paradigm antithetical to efficient strings? #Haskell
by KC 14 Jul '16

14 Jul '16

Is the #functional programming paradigm antithetical to efficient strings? #Haskell -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey

12 20

Use GHC API in standalone executable?
by Mitchell Rosen 14 Jul '16

14 Jul '16

Hi, I'd like to compile an executable that internally uses the GHC API, but otherwise does not require users to have GHC installed on their machine. Is this possible? As far as I can tell, lots of functions in the GHC API read package databases per $GHC_PACKAGE_PATH and things of that nature. Thanks, Mitchell

1 0

Can't log into to GHC trac
by Mitchell Rosen 13 Jul '16

13 Jul '16

Hi, embarrassingly I've forgotten my password (and username) to the GHC trac, and there's no automatic way to reset any of it: - When I try to register an account it says my email address is already in use - To reset my password I need to give both my username and password, but I don't know my username Who can I contact to help resolve the issue?

1 0

ANN: tagsoup-megaparsec-0.1.0.0
by KwangYul Seo 13 Jul '16

13 Jul '16

Hello all, I'm pleased to announce the first release of tagsoup-megaparsec, a Tag token parser library. This library helps you build a megaparsec parser using TagSoup's Tags as tokens. https://hackage.haskell.org/package/tagsoup-megaparsec https://github.com/kseo/tagsoup-megaparsec Regards, Kwang Yul Seo

3 3

Cannot install any packages after upgrading to GHC 8.0.1
by Magicloud Magiclouds 12 Jul '16

12 Jul '16

Hi, I update my GHC to 8.0.1 and failed to install any packages since then. If I use cabal, I got 'installed package info from too old version of Cabal (key field does not match id field)' for every package. If I use Setup.hs, I got 'Configuring Cabal-1.24.0.0... Setup.hs: ghc-pkg dump failed'. What should I do? Googling did not get me an answer.

4 4

Re: [Haskell-cafe] Is the #functional programming paradigm antithetical to efficient strings? #Haskell
by Alex Belanger 11 Jul '16

11 Jul '16

That's not just about Haskell, it's C.S. in general. You're always going to make space and time tradeoffs. Funny how the same constraints appear in physics; I wonder if it is trying to tell us something... - nitrix On Jul 11, 2016 8:54 AM, "David Fox" <dsf(a)seereason.com> wrote: On Sun, Jul 10, 2016 at 11:44 AM, KC <kc1956(a)gmail.com> wrote: > Is the #functional programming paradigm antithetical to efficient strings? > #Haskell > I can certainly see how it might seem so. Our main string representation uses about 10 times more memory than seems necessary, and is relatively fast, though probably not compared to C. Recently I spent some time looking into how to reduce this memory overhead, and I modified the pretty library (https://github.com/ddssff/pretty/tree/textdetails) so it could use any type that was an instance of ListLike and StringLike ( https://github.com/JohnLato/listlike) Then I tried the UnitLargeDoc test with several different data types. This just concatenates a list of ten million "Hello" strings. Using String this happens in about 5 seconds. Using strict or lazy Text it immediately blew the stack. When I increased the stack size to over 1GB it took minutes to complete. When I used the Data.Text.Lazy.Builder type instead it took about 30 seconds to complete. Results with utf8 encoded ByteStrings were siimilar. When I mentioned some of this, I was told "different data structures for different purposes", which sort of makes sense, but honestly if Haskell is a language where you have to sit down and choose a representation every time you want to build some text, I get a bit discouraged. So is functional programming antithetical to efficient strings? In theory maybe not, but I would love to see some hard evidence. </rant> _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

1 0

ANN: enchant-0.1.0.0
by KwangYul Seo 11 Jul '16

11 Jul '16

Hello, I'm happy to announce the first release of enchant, binding for the Enchant library. https://hackage.haskell.org/package/enchant-0.1.0.0 https://github.com/kseo/enchant What is Enchant? (from http://www.abisource.com/projects/enchant/) On the surface, Enchant appears to be a generic spell checking library. You > can request dictionaries from it, ask if a word is correctly spelled, get > corrections for a misspelled word, etc... > > Beneath the surface, Enchant is a whole lot more - and less - than that. > You'll see that Enchant isn't really a spell checking library at all. > > "What's that?" you ask. Well, Enchant doesn't try to do any of the work > itself. It's lazy, and requires backends to do most of its dirty work. > Looking closer, you'll see the Enchant is more-or-less a fancy wrapper > around the dlopen() system call. Enchant steps in to provide uniformity and > conformity on top of these libraries, and implement certain features that > may be lacking in any individual provider library. Everything should "just > work" for any and every definition of "just working." Thanks, Kwang Yul Seo

1 0