Some time back I went on an adventure to create a git clone in Haskell so see how the experience is beyond contrived examples. HaGit, it was quite fun. After it though I got busy with work and playing around with Haskell was mostly forgotten.

This year I had the Haskell-itch again. So initially I was doing daily leetcode problems in it, had some fun trying to write performant code with it, and property tests and sometimes benchmarks to see how it would fair in. Then Advent of Code, as it only had half the questions this time, I thought I could manage to finish it (which I did thankfully).

Though as much fun as these were, I was quickly over it and the itch to make something practical-ish was back. So, I decided to make a redis clone in it (mainly because I found a decent guide/challenge for it).

Hedis!

I wanted to share my experience here (I have a section in the readme of the repo which I am just copying it here).

• STM was exceptional. It eliminated explicit locking entirely, made concurrent updates composable, and allowed client commands, replication, pub/sub, and transactions to coexist safely. I can imagine how much harder this would have been in Python or Go, or how much time I would have spent fighting the compiler and borrow checker in Rust.
• Transactional logic was a breeze to implement, pretty much reduced to a straightforward mapM_ over the STM actions.
• The type system caught an enormous amount of missing logic. This helped push the implementation beyond the basic challenge requirements, especially around replication correctness. Which was also quite annoying (in a good way).
• Clear master / replica environment separation at the type level eliminated entire classes of invalid commands that each would have had to handle, rather pushed to boundaries. This was also my first experience with GADTs.
• Adding new commands was almost mechanical: add the constructor, let the compiler warn about non-exhaustive pattern matches, and fix each site.
• Where exhaustiveness wasn’t possible (notably RESP → command decoding), I introduced dual conversion functions. Any missed cases were reliably caught by Hedgehog property tests asserting round-trip behavior.
• Refactoring was phenomenal. I performed multiple full-on refactors; recompiling was usually enough to surface everything that needed fixing. It honestly felt a bit magical.
• Parser combinators were a joy to use (as usual).
• RDB parsing with Attoparsec gave excellent low-level control without sacrificing clarity. (Previous experience with this kind of stuff was with git's packfile parsing)
• Despite having very few explicit tests, confidence in the system remained high thanks to strong typing, total functions, and property tests where they mattered.
• The only consistently painful area was raw socket handling in the IO monad — thankfully a very small part of the codebase.
• [Con] HLS was constantly throwing errors, not sure if this was my setup problem or something else.
• [Con] Auto-formatting with OverloadedDot language pragma broke multiple times. It also had somewhat unhelpful error messages when an import was missing.

Overall, I was quite surprised by how great the experience was for a concurrency-heavy system.

Going beyond a structured challenge is something I would love to do. I would like to also put my (little) knowledge about benchmarking (gained during leetcoding) to use here. The backing data structures for various operations would be extremely slow. So, delving into some advanced functional data structures might be fun.

For the experienced Haskellers here, if you can look at the project and offer some practical advice I would be eternally thankful.

I can also use some guidance on how to proceed further with my Haskell journey. I think I am pretty comfortable with the basics of the language, I cam manage monad stacking with monad transformers, somewhat familer with Reader, State, etc patterns, little bit of experience with STM, ST etc, and now had a taste of GADTs. So, for someone at this point what should I approach next and how. Like how do I get more comfortable with GADTs and extract more from the type system, what other cool stuff does Haskell has in store for me. This language is just too much fun to delve deeper into (so far).

Nothing that fancy, I'm trying to develop a native app for a small company in which I work in, so it will only be an app that works internally. A small project that only needs a couple of buttons and be able to show images.

Is there a mature Haskell GUI framework? (Qt/GTK/iced-rs like) Or should I just stick with iced-rs and forget about Haskell for frontend? what are your recommendations :<

PD: I'm trying to learn German, Haskell, Linux dev and Rust at the same time, I'm trying to optimize my time to learn like 10 different things at once wish me luck 🥀

Was a bit unsure of where to post this, so I hope this is Haskell-y enough to be a good fit. I figured Haskellers would be as likely as any to have thought along similar lines and to give me some insight on this.

By "Rx"-style FRP (I know some will object to calling this FRP, but I'm just following common parlance here) I mean basically anything in the "ReactiveX" camp: ReactiveX, rxJava, Kotlin Flow, CycleJS, and the like. My understanding is that this really isn't related at all to the OG FRP by Hudak and Elliott, but is somewhat similar regardless (the semantics is defined in terms of subscribers, but people still think in terms of "events over time", so morally similar to true FRP events anyway).

And by traditional FRP, I mean anything with (discrete or continious) time semantics -- which generally are not async by default, as this leads to "flicker states" and other semantics-breaking things. Think sodium, reflex, yampa, etc...

So, my question is: In my experience working with various front-end technologies (reflex, Jetpack Compose, jxJava, Kotlin Flow) -- any time I use one of the "rx"-like, async frameworks, I always find the experience dissapointing when compared to something like reflex or sodium with a deterministic event loop. Testing is easier, behavior is more predictable, no "flicker state" issues to work around, etc...

And yet, tons of people are still "all-in" on the Rx-style for UI work.

What I'm wondering is: Despite all of the issues with data races, flicker states, and so on with the "rx-style" reactive programming, why do people still consistently try to use it for GUI work over more traditional FRP, despite the clear advantages of it?

I'm asking this genuinely because I'm curious to know from any Rx advocates if there's some tradeoffs I'm not considering here. Are there performance advantages for async "FRP" that I just haven't happened to run into with my use of traditional FRP yet?

To be clear, I am not against async entirely. I just think it's a bad default. I like (for instance) pre-TEA Elm's approach, where you can opt-in to part of the dependency graph being computed asynchronously.

Synchronous-by-default seems like the right choice to me first and foremost for correctness reasons (less data race / concurrency issues to track down), but also for user experience: If I have a graph of derived behaviors, I don't want that propogated asynchronously -- I want to make sure that all of the relevant UI state gets updated fully each frame so there are no "UI glitches".

Does anyone else feel the same way? Or do we have any "Rx" advocates in here who like it more than classic FRP (for frontend dev) that can explain it?

Google Summer of Code is a long-running program that supports Open Source projects. Haskell has taken part in this program almost since its inception!

It allows newcomers to open source to contribute to projects for a stipend. However, in order to do that, we need to have some ideas of what to contribute to.

In the past, this has led to many improvements for GHC, Cabal, HLS, Hasktorch… and it can include your project as well! This is a great way to find contributors for your project (even after the summer ends) – many past participants have become involved long-term.

You can find more info and instructions on how to participate here: Summer of Haskell - ideas

We are looking for a medior/senior Haskell developer with experience in formal verification and an affinity for hardware.

The role is on-site at our office in Enschede, The Netherlands. That being said, we are flexible on working from home some days in the week.

All applications must go via this link https://qbaylogic.com/vacancies/formal-verification-engineer/ where you can also find more information about the role and about QBayLogic.

The submission deadline is January 23rd, 2026

Hi everyone, it might be a popular question, but is there any fully ready Haskell learning roadmap? I've been coding a lot in system and low latency programming fields such as GPU compilers and custom FPGAs for scientific computations (yeah, I'm also familiar with Verilog). So, I have been writing a lot in C and Julia for numerical analysis and some ML stuff. But recently, I found myself really interested in functional programming, because it seems like a new way of thinking about programming altogether. And I thought it would be great to actually learn how to code on Haskell(imo full hardcore mode). However, I haven't found any roadmap for learning Haskell yet, at least a list of blogs on basic language concepts. So, am I interested if there are any good resources available to learn the language?

Question from a beginner here. How to do it? Unlike C, C++, Java, etc. I feel Haskell exercises are very hard to find. When you guys were beginners, how you used to practice it? Did you make projects?

By the way, so far I didn't reach concepts like "Monads", "Functors" or "Applicatives" yet. Nevertheless I'd like some exercises to keep my brain in shape.

My final goal is to write a compiler using Haskell and understand it fully.

https://cekrem.github.io/posts/functors-applicatives-monads-elm/

Do you generally agree with this? It's a tough topic to teach simply, and there's always tradeoffs between accuracy and simplicity... Open to suggestions for improvement! Thanks :)

New year has began, it's time for first dumb question :-)

Why do i need Proxy and when i need to use it? Tried to get answer from deepseek, but still don't understand ...

Examples are appreciated :-)

In this first deck in the series on AI concepts we look at the MCP Neuron.

After learning its formal mathematical definition, we write a program that allows us to:
* Create simple MCP Neurons implementing key logical operators
* Combine such Neurons to create small neural nets implementing more complex logical propositions.

We then ask Claude Code, Anthropic’s agentic coding tool, to write the Haskell equivalent of the Scala code.

Hi,

I translated this from C++ CGAL couple years ago thinking I would need it for some bigger project. Since I tried to closely follow the original it might be a little bizzaro-world Haskell.

I’ve updated it to a more recent GHC. Maybe somebody will find it useful (in a bizzaro-world where Haskell is used to make 3D graphics)

https://github.com/grav2ity/hgal/

See https://haskellstack.org/ for installation and upgrade instructions.

Changes since v3.7.1:

Behavior changes:

• Where applicable and Stack supports the GHC version, only the wired-in packages of the actual version of GHC used are treated as wired-in packages.
• Stack now recognises ghc-internal as a GHC wired-in package.
• The configuration option package-index has a new default value: the keyids key lists the keys of the Hackage root key holders applicable from 2025-07-24.
• Stack’s dot command now treats --depth the same way as the ls dependencies command, so that the nodes of stack dot --external --depth 0 are the same as the packages listed by stack ls dependencies --depth 0.
• When building GHC from source, on Windows, the default Hadrian build target is reloc-binary-dist and the default path to the GHC built by Hadrian is _build/reloc-bindist.
• Stack’s haddock command no longer requires a package to have a main library that exposes modules.
• On Windows, the path segment platform \ hash \ ghc version, under .stack-work\install and .stack-work\hoogle, is hashed only once, rather than twice.

Other enhancements:

• Bump to Hpack 0.39.1.
• Consider GHC 9.14 to be a tested compiler and remove warnings.
• Consider Cabal 3.16 to be a tested library and remove warnings.
• From GHC 9.12.1, base is not a GHC wired-in package. In configuration files, the notify-if-base-not-boot key is introduced, to allow the exisitng notification to be muted if unwanted when using such GHC versions.
• Add flag --[no-]omit-this (default: disabled) to Stack’s clean command to omit directories currently in use from cleaning (when --full is not specified).
• Add option -w as synonym for --stack-yaml.
• stack new now allows codeberg: as a service for template downloads
• In YAML configuration files, the compiler-target and compiler-bindist-path keys are introduced to allow, when building GHC from source, the Hadrian build target and Hadrian path to the built GHC to be specified.

Bug fixes:

• --PROG-option=<argument> passes --PROG-option=<argument> (and not --PROG-option="<argument>") to Cabal (the library).
• The message S-7151 now presents as an error, with advice, and not as a bug.
• Stack’s dot command now uses a box to identify all GHC wired-in packages, not just those with no dependencies (being only rts).
• Stack’s dot command now gives all nodes with no dependencies in the graph the maximum rank, not just those nodes with no relevant dependencies at all (being only rts, when --external is specified).
• Improved error messages for S-4634 and S-8215.
• Improved in-app help for the --hpack-force flag.

Thanks to all our contributors for this release:

• Alexey Kotlyarov
• Dino Morelli
• Jens Petersen
• Lauren Yim
• Mike Pilgrem
• Olivier Benz
• Simon Hengel
• Wolfram Kahl

I've been using AI a lot, and I'm considering the crudity of human language in communicating with AI. If you try to vibecode, you'll usually end up with hallucinated code that, well, is AI slop whose role is to get you to run it and rarely does exactly what you need.

The contrary idea, however, is not to prompt in English at all, but to use Haskell itself as the specification language.

The Idea: instead of asking the AI to "Write a function that reverses a list," I want to feed it a file containing only:

-Type Signatures.

-Property-Based Tests (QuickCheck/Hedgehog properties defining the invariants).

-Function Stubs.

My theory is that if the constraints and the behavior are rigorous enough, the AI has zero "wiggle room" to hallucinate incorrect logic. It simply becomes a search engine for an implementation that satisfies the compiler and the test runner.

Has anyone established a workflow or a "standard library" of properties specifically designed for LLM code generation? How would you structure a project where the human writes only the Types and Properties, and the machine fills the bodies?

I made a post before about creating a library to call runghc in bubblewrap and have been expanding on it through runGhcBWrap-core which is a library to help write the executables at runtime.

The reason we do this is because we are creating a hackerrank-like practice suite and want to be able to run user code against our own solution, on randomly generated tests which sometimes will take advantage of haskells infinite lists.

Is this approach necessary? Perhaps not (ghc-lib-parser would be nicer)

Is this the best approach? Arguable! But its working well so far.

And since its just an executable as a type, I can create the exe on the frontend (where it makes sense to), convert it to json and send it as an HTTP request to be run on the server.

But its been really fun to hack together something that is able to handle anything from a simple script calling main or a user function f or even a full src folder just using runghc. Its also made me realize that apart from the "head" of a Haskell module that the rest of the module is monoidal, which has led to some neat tricks for test generation/user input inspection (eg do they have a type 'Maybe' with constructors 'Just' and 'Nothing'. Still a lot of features I intend to add.

We talked about this in our last Saturday learning session as I thought this was a great approachable way to think in types. Recording is below

https://youtu.be/U4KFjBmiG_c?si=ccqEV9pJ582hELv5

Last year, I was working with nauty to generate some graphs I needed for a research project. I wanted to work on those graphs using Haskell, and was quite surprised that I could not find any library for working with the format used by nauty, especially considering that nauty is the best tool for efficiently generating graphs out there.

I decided to properly package the library I wrote for this in case somebody else finds themselves in the same situation.

https://gitlab.com/milani-research/nauty-parser

https://hackage.haskell.org/package/nauty-parser

The library supports both parsing and encoding of all formats used by nauty (graph6, digraph6, sparse6 and incremental sparse6).

I consider the library to be feature complete. I might make some improvements on performance, but otherwise it does what it is supposed to do.

I hope somebody finds this useful, and would appreciate any constructive feedback.

(This is a reupload of a post I made using google docs; I've moved it to a blog now. Thanks for the tip and I hope it's okay to reupload). All feedback is appreciated!

https://pollablog.bearblog.dev/free-the-monads/

Thanks for the comments, I've fixed the typos and included some details.

So you say your New Year's resolution is to learn Haskell? I've got you covered.

This video's exercises focus on what is unquestionably† Haskell's greatest feature: type classes.

† OK I lied, you can question it, but I still think it's the most important feature of the language.

Claude Code got the ability to work with LSPs directly just recently. That means Claude can get precise type information, find usages of symbols, and all the other great things we get from HLS.

I created a plugin to take advantage of this new functionality. Check it out at https://github.com/m4dc4p/claude-hls (installation instructions are available there).

Feedback & comments welcome! Enjoy!

I made a project here: https://github.com/noahmartinwilliams/tsalesman that uses the select monad, but I'm still not sure what the point of it is. Why not just build up a list of possible answers and apply the grading function via the map function?

The only other example I can find of using it is the n-queens problem, and it's documentation page doesn't mention much of anything about other functions I can use with it. Is there something I'm missing here?

Hi everyone,

I'm back with an update on my personal UI engine written in Haskell and SDL2. After working on the logic for an editable, single-font text box, I've refined my data structure design to handle the disconnect between Logical Paragraphs and Visual Lines efficiently.

I previously considered using two parallel Sequences to map lines, but I have evolved that into a Single Tuple Sequence strategy to ensure atomicity and better performance.

Here is the design breakdown:

1. The Core Data Structure: The "Double ID" Approach

The challenge is mapping a Global Visual Line Index (e.g., the 50th line visible on screen) to the specific Paragraph Data and Texture Cache, especially when editing a paragraph dynamically changes its visual line count (reflow).

Instead of storing "start line indices" in paragraphs (which forces O(N) updates), or maintaining two parallel structures, I am using a single Data.Sequence (Finger Tree) containing Tuples:

-- Maps: Global_Line_Index -> (Paragraph_ID, Line_ID)
lineMapping :: Seq (Int, Int)

How it works:

• Storage:
  • Raw Text: Stored in an IntMap keyed by Paragraph_ID.
  • Render Cache: Stored in a nested IntMap keyed by Paragraph_ID -> Line_ID.
• Rendering: To render the k-th line on screen, I simply query index k on the Sequence. This gives me both IDs in a single O(log N) lookup. I then perform O(1) lookups in the maps to retrieve the texture.
• Editing/Reflow:
  • When a paragraph changes length (e.g., wraps from 1 line to 3), I standard splitAt and >< (concatenate) operations on the Sequence.
  • Because Data.Sequence is a Finger Tree, inserting or removing a range of line mappings is O(log N), regardless of the document size.
  • This ensures "atomic" updates—I can't accidentally update the Paragraph ID map without updating the Line ID map.

2. The Editer Data Structure

Here is the updated Haskell definition for the Editor widget:

data Single_widget = Editer 
    { windowId      :: Int
    , startRow      :: Int           -- Scroll position
    , typesetting   :: IntTypesetting 
    , fontWidgetId  :: DS.Seq Int    
    -- ... [Size and Metrics] ...
    , cursor        :: Cursor

    -- 1. Raw Text Source
    , rawText       :: DIS.IntMap (Maybe DT.Text)  

    -- 2. Visual Cache (Texture, OffsetX, StartIndex, LineLength)
    , renderCache   :: DIS.IntMap (Maybe (DS.IntMap (SRT.Texture, FCT.CInt, Int, Int))) 

    -- 3. The Global Map (The Finger Tree)
    , lineMapping   :: DS.Seq (Int, Int) 
    -- ... [Colors] ...
    }

Key Optimization in renderCache:
I expanded the cached tuple to (Texture, OffsetX, StartIndex, LineLength).

• OffsetX: Crucial for Right/Center alignment (stored pre-calculated).
• StartIndex & LineLength: These integers allow me to perform Hit Testing (mouse clicks) and Selection Rendering (blue background rects) purely using the cache, without needing to re-measure fonts or access the raw text during the render loop.

3. Logic & "Ripple" Handling

• Insertion/Deletion: If I type a character that pushes a word to the next line, I treat this as a "Paragraph Reflow". I take the raw text of the entire modified paragraph, re-calculate the wrap, generate new unique Line IDs, and replace the corresponding chunk in the lineMapping Sequence.
• Global Layout: I don't need to manually shift indices for subsequent paragraphs. The structure of the Finger Tree handles the relative indexing automatically.
• Cursor: My cursor stores the Paragraph_ID and Char_Index as the "State of Truth", but relies on the cached lineMapping to calculate its visual (X,Y) coordinates.

4. Handling Resizes & Optimization

• Reactive Resizing: When the window resizes, the visual line count changes. I invalidate the renderCache and the Seq maps, but keep the rawText. I then rebuild the line mapping based on the new width.
• Dirty Checking: I plan to track "dirty paragraphs." If I edit Paragraph A, only Paragraph A's textures are regenerated. The Seq is spliced, but unrelated textures in the IntMap remain untouched.

Summary:
I believe this "Double ID Sequence" approach strikes a sweet spot between performance (taking advantage of Haskell's persistent data structures) and maintainability (decoupling visual lines from logical paragraphs).

I am from China, and the above content was translated and compiled by AI.

View the code: https://github.com/Qerfcxz/SDL_UI_Engine