Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use case for strict list #34

Open
rubenmoor opened this issue Dec 14, 2021 · 0 comments
Open

Use case for strict list #34

rubenmoor opened this issue Dec 14, 2021 · 0 comments

Comments

@rubenmoor
Copy link

Quoting the package documentation

Note that this library does currently not provide fully strict lists. They can be added if they are really required. However, in many cases one probably wants to use unboxed or strict boxed vectors from the vector library (http://hackage.haskell.org/package/vector) instead of strict lists. Moreover, instead of Strings one probably wants to use strict Text values from the text library (http://hackage.haskell.org/package/text).

I agree with that advice. I think I have a use case for a strict list, though. Maybe you can provide feedback in how far it is valid and this issue can serve to elaborate the usefulness of a strict List type.

I use a foldable (a vanilla lazy list) to fold it into another foldable (I use a strict list here). I want that second foldable to be strict in its argument type to avoid the memory load that otherwise comes with the thunks.

Those are the steps of my algorithm:

  1. My first list contains between 2'000'000 and 4'000'000 words and has the type [Text].

  2. I then run parseSeries on every word, a CPU-heavy algorithm of type Text -> Either ParseError [RawSteno]. Because it's CPU-heavy, I run it concurrently. The result is collected in the strict list, which has less entries than the list of words from Step 1.

  3. Finally, the pairs (Text, [RawSteno]) are folded for into a strict hashmap. It's not just HashMap.fromList, because of some further logic where entries are checked for collisions with former entries. That same logic requires this step to be single-threaded again, which is fine given that it's not nearly as performance-heavy as Step 2.

I don't see a reason to work with vector, when I really just need a foldable that is strict in the argument type. I do understand that I could work with vector. Maybe someone can point out that I should.

Btw, if all were single threaded, I would benefit from Haskell's laziness. Haskell could rush to step 3 for every word of Step 1. With concurrency I get a good speed-up but also the requirement to collect that strict foldable in Step 2 entirely before I can move on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant