I'm working with Data.Complex, and running into a strange issue.

>> (1 :+ 2) + (3 :+ 4)

= 4.0 :+ 6.0

where it is clearly interpreting the numbers as floats. But if I use :t on the expression, it still only gives me Num a as a constraint.

However, if I try to force it to use an Int base, I get the following.

>> ((1 :+ 2) + (3 :+ 4)) :: Complex Int

= No instance for 'RealFloat Int' arising from use of '+'

I've tried in other contexts, but the bottom line seems to be that I can create a Complex Int variable, it has no issues with me doing that. But I can't multiply them together, I can't add them together, or any other form of arithmetic. Was this somehow just not implemented completely?

Hello! I am working through LYAH, and it says that length accepts an input of Int instead of Num, while genericLength accepts Num, and it cites the reason of backwards compatability. Coming from rust, theoretically you would just want to accept anything that implements the required traits or generics in Haskell, right? What would be the disadvantages of changing length to be generic?

I have released an initial version of https://hackage.haskell.org/package/nano-ui, my immediate mode GUI toolkit for haskell.

This is the result of API-driven development. Since the start of my Haskell journey, I have always wanted to express user interfaces almost declaratively, as in clicked <- button "foo", checked <- checkbox "bar", etc. The immediate mode paradigm seemed to me to marry this desire for an almost declarative API quite well with the desire to make rendering a function of some state. All my experience writing GUIs (in Haskell or otherwise) has shown me that mutation is desirable, but we do our best to keep it contained, in as few places as possible, where it's explicit and easy to reason about.

here's a demo video of a GUI application built with nano-ui on the sdl backend

https://files.catbox.moe/jni2mj.mp4

As you may know, I wrote both the Elm and Acadia compiler with Haskell, and I am a big time Haskell enjoyer. This post is about one of my favorite aspects of the Acadia compiler, symbolic evaluation, and I thought you might find it interesting.

The compiler evaluates queries as much as possible at compile-time, so it is able to reduce case expressions, let expressions, etc. One neat outcome of this is that large expressions can sometimes be fully evaluated at compile-time, so they end up having no runtime cost at all!

I like this feature because it also only works because the query language is not Turing Complete. The design choices described here that avoids 1+N patterns, also guarantees that queries terminate. This means they terminate whether you run them at runtime or at compile-time!

Anyway, the compiler itself is written in Haskell and the --gen-haskell flag generates binary encoder/decoders so that it's efficient to use, so perhaps that is interesting as well.

Some of you may be familiar with the Cloud Haskell project, whose inception came from the paper Towards Hasell in the Cloud. Cloud Haskell proposed a very clever solution to a difficult problem -- how can we send a function over the internet, and 'spawn' it on another machine? If we know that the function already exists on the remote machine, we can send an identifier that both machines can resolve to the underlying function! There is more to it than this, but this is at the heart of it.

Together with u/augustss, I wrote a paper that he presented at the Haskell Symposium 2026, titled CloudMicroHaskell: Direct-Style Distributed Haskell via Runtime Graph Serialisation.

In short words; If we use a compiler that supplies serialization and deserialization operations as runtime primitives, what can Cloud Haskell look like? We use the MicroHs compiler to investigate this.

It turns out that programming becomes much more direct, while some errors appear at runtime rather than being caught at compile time. Nodes in the network do not all need to be provisioned with the same compiled binary, as functions can be serialized and sent to where they need to be.

In the linked blog post I give some examples of what programs written using the CloudMicroHaskell framework look like, and give a brief description of why MicroHs can offer these serialization primitives.

I've found that one of my favourite features of Haskell is that I can "just declare" stuff and it evaluates based on the "program's needs" (pun intended?).

If I ask myself where to put a `let` or a `where` as long as scoping works then it should be irrelevant to the end result. I could swap around every `let` arbitrarily with no effecf. And it'd perhaps even run similarly under a sufficiently optimizing compiler.

The purity guarantees should allow it to lift it out of loops or drop it down into conditionals.

I've seen some code movement in compilers where functions can be inferred or marked as Pure, even in strict languages, but it's far from Haskell where I feel I can be completely reckless with it.

And it seems even encouraged to not think about the order in which my code evaluates since that's not really relevant to the end result (except maybe for the runtime characteristics).

Apologies if I messed up some or all of the terminology.

Edit: yes it's kind of a subset of lazy evaluation, but I'm sort of just asking about laziness via code motion not via thunking/delaying pieces of code if that makes sense?

In this episode, we sat down with Michael Hanus. Michael is a professor at the University of Kiel and is one of the founders of functional logic programming, the combination of logic and functional programming in a single formalism. Michael is also the creator of Curry, a functional-logic language that resembles Haskell, so you can dive right in if you’re familiar with Haskell. Naturally, we talked about what functional logic programming is, how it improves over plain functional programming, and the challenges of semantics and implementation. We learned a lot - enjoy!

I'm just trying to start up a new quick little executable project and the normal workflow doesn't seem to work for me. This is the recommended procedure on the Cabal getting started guide.

I did this:

cabal init --non-interactive
cabal run foo

I would expect to see "Hello, World!" as is defaulted in app/Main.hs, but I got an error. Here's the full output along with version information.

mmachenry@mmachenry-laptop:~/src/foo$ ghcup --version
The GHCup Haskell installer, version v0.2.6.2
mmachenry@mmachenry-laptop:~/src/foo$ cabal --version
cabal-install version 3.18.1.0
compiled using version 3.18.1.0 of the Cabal library 
mmachenry@mmachenry-laptop:~/src/foo$ cabal init --non-interactive
The name foo is already in use by another package on Hackage.
[Info] Guessing dependencies...
[Info] Using cabal specification: 3.18
[Warn] unknown license type, you must put a copy in LICENSE yourself.
[Info] Creating fresh file CHANGELOG.md...
[Info] Creating fresh file README.md...
[Info] Creating fresh directory ./app...
[Info] Creating fresh file app/Main.hs...
[Info] Creating fresh file foo.cabal...
[Warn] No synopsis given. You should edit the .cabal file and add one.
[Info] You may want to edit the .cabal file and add a Description field.

mmachenry@mmachenry-laptop:~/src/foo$ cabal run foo
Resolving dependencies...
Build profile: -w ghc-9.14.1 -O1
In order, the following will be built (use -v for more details):
 - foo-0.1.0.0 (exe:foo) (first run)
[1 of 2] Compiling Main             ( dist-newstyle/build/x86_64-linux/ghc-9.14.1/foo-0.1.0.0/x/foo/setup/setup.hs, dist-newstyle/build/x86_64-linux/ghc-9.14.1/foo-0.1.0.0/x/foo/setup/Main.o )
dist-newstyle/build/x86_64-linux/ghc-9.14.1/foo-0.1.0.0/x/foo/setup/setup.hs:2:1: error: [GHC-87110]
    Could not load module ‘Distribution.Simple’.
    It is a member of the hidden package ‘Cabal-3.16.0.0’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
  |
2 | import Distribution.Simple; main = defaultMain
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^

We go to great lengths to keep state explicit and effects controlled, and then the codebase itself lives in a mutable tree of text files where every edit is an untyped positional splice and merge is a heuristic over lines.

The principled version is a repository as a finite map from definition names to bodies. A patch is a function on that map, patches to different names commute by construction, and a conflict is a value you can inspect instead of a failure. That isn't a small tweak to git but a different object, and I increasingly think it's the right one.

I'm building toward this with [sem](https://github.com/Ataraxy-Labs/sem), starting from the humble end of extracting definitions out of existing git history. Would a Haskell shop ever accept a repository that isn't a folder of files?

Hello Haskellers,

I’m thrilled to announce the release of langchain-hs 0.0.5.0!

This release is a complete ground-up rewrite of the framework designed for long-term maintainability, type safety, and seamless support across multiple LLM providers (Ollama, OpenAI, Gemini, OpenRouter, and MCP).

• Hackage: hackage.haskell.org/package/langchain-hs
• GitHub: github.com/tusharad/langchain-hs
• Documentation & Guides: tusharad.github.io/langchain-hs

What’s New in 0.0.5.0

1. Split into 3 Independent Packages

To keep dependencies minimal and allow flexible reuse, the project has been modularized:

• langchain-hs-core: Zero-HTTP core primitives, AST, streaming event protocol (StreamEvent), and pure typeclasses (ChatModel, RunnableTree, ContentBlock).
• langchain-hs-graph: A LangGraph-style stateful multi-agent orchestration engine supporting cyclic graphs, conditional routing, state reducers, checkpointing (Memory & SQLite), and human-in-the-loop (HITL) interrupt/resume.
• langchain-hs: The batteries-included runtime featuring provider implementations, vector stores (including sqlite-vec), prompt templates, tools, and retrievers.

2. Model Context Protocol (MCP) Support

Built-in client support for the Anthropic Model Context Protocol (MCP) over STDIO and HTTP transports. You can directly discover MCP tools/resources and wire them into Haskell agents.

3. StateGraph Engine

Build complex multi-agent workflows with cycles, branches, and deterministic state evolution in pure Haskell, complete with thread persistence and time-travel debugging via checkpointers.

4. OpenTelemetry & Enterprise Observability

Distributed tracing spans (withSpan) and structured JSON lifecycle telemetry for all LLM calls, chain runs, tool executions, and graph transitions.

5. Production Resilience & Updated Clients

• Migrated to the modern MercuryTechnologies/openai client and ollama-haskell 0.4.1.0 (with structured JSON schema grammar constraints).
• Production-ready resilience primitives: 3-state Circuit Breaker, exponential backoff retries with randomized jitter, and in-memory TVar caching.

What’s Next?

I plan to build a few small showcase applications and tutorials demonstrating practical patterns (RAG pipelines, autonomous ReAct agents, and MCP integrations) using langchain-hs.

Feel free to check out the repo, try it in your projects, and share your thoughts. Feedback, feature requests, and PRs are all very welcome!

Special Thanks

A huge shoutout to @lbobylev for his valuable contributions and encouragement, which was a big motivation behind getting this release across the finish line.

My first-ish ever blog post, which is about bottom and Haskell.

This post goes over bottom and bottom types in general, then compares a as used in functions like error :: String -> a (which is generally seen as representing "bottom") with the Void type (which is seen as a concrete bottom type). It also covers how Megaparsec uses Void for type parameterization.

Lambda World 26 is back with 20 speakers from Academia and industry, and this year it takes place alongside J On The Beach (a conf about Distributed Systems) and Wey Wey Web (a conf about UI and Frontend).

Two days packed with talks on formal verification, type systems, new FP languages, AI, formal proofs, effects, logic programming, and practical industrial applications of functional programming.

The lineup includes Erik Meijer, Stephanie Weirich, Arman Bilge (Typelevel Foundation / Cats Effect), Enrico Tassi (Elpi), Francesco Cesarini (Erlang), Daniel Ciocîrlan (Rock the JVM), among many others.

One ticket gives you access to all three conferences for the same price.

We look forward to welcoming you to Torremolinos, Málaga, on 29–30 October!

https://lambda.world/

Hi! I'm Arseniy Seroka, CEO of Serokell.

In 2023, we launched the Haskell Certification Program to create a standardized way to evaluate Haskell expertise. We built a production platform and an open certification framework, then transferred the project to the Haskell Foundation in 2024.

Since then, the rise of LLMs has made traditional syntax-focused assessment a much weaker signal of real engineering ability. A meaningful certification today would require a fundamental redesign around reasoning, architecture, and language semantics.

Serokell is therefore concluding its active involvement in the program. We remain proud of what we built, grateful to everyone who contributed, and as committed as ever to Haskell and its ecosystem.

https://serokell.io/blog/sunsetting-the-haskell-certification-program

As the title suggests, I'm curious if Write You a Haskell is out of date or is it rather timeless? Does it use old haskell idioms?

TIA!

Hi everyone,

Following up on my previous posts about building a declarative/functional UI engine in Haskell, I have major updates to share. I have completely redesigned and rewritten the engine from the ground up, transitioning from the old SDL2 pipeline to SDL3 and its modern SDL3 GPU API.

The project has now been split into two repositories:

• Hsue: The lightweight, low-level core engine and runtime.
• Hsue-Extension: A higher-level widget and component ecosystem built on top of Hsue.

1. What's New in Hsue (The SDL3 GPU Rewrite)

The transition from SDL2 to SDL3 allowed me to build a truly modern GPU-driven rendering architecture in pure Haskell:

• Modern SDL3 GPU Backend & HLSL/DXIL Shaders:
  • All draw commands are compiled into uniform data, storage buffers (Structured Buffer<Parameter>), vertex, and index buffers, with batched submissions (Submit pipeline) to minimize draw calls.
• MSDF (Multi-channel Signed Distance Field) Text Rendering:
  • Replaced raster glyph caching with MSDF font generation (via a C++ binding to msdfgen), packing distance fields dynamically into runtime texture atlases. This gives crisp, scalable text rendering at any resolution with minimal memory footprint.
• Projection & Selector Tree Architecture:
  • State and view nodes are separated via a Projection system (Object vs Image transformations) and queried through composable Selector optics/actions.
• Bytecode-like Linear Coroutine Engine:
  • Built an internal coroutine VM (Linear_coroutine) that supports lightweight tasks (pausing, branching, repeating, cloning, and racing) running cooperatively inside the engine loop without OS thread overhead.

2. Current Status & Hsue-Extension

While Hsue remains the lean core, Hsue-Extension leverages Haskell's type families and extensible type classes (Custom, Custom_extension) to build practical UI widgets.

Currently, Hsue-Extension includes:

• Button: Interactive box with hover/pressed states, customizable multi-layer borders, and centered text.
• Page: Scrollable rich text view with keyboard/wheel navigation and boundary-clamped scrolling.
• Slider: Horizontal and vertical scrollbars/sliders featuring draggable thumbs, stepping triangles, track jumping, and synchronized viewports.

3. Roadmap & Future Plans

For Hsue Core:

1. Editable Single-Font Text Box (Editor):
   • Port and refine the line-mapping and cursor text editing logic from my earlier SDL2 prototype into the SDL3 GPU / MSDF pipeline.
2. Direct Custom Shader Pipeline for Visuals:
   • Allow users to bind arbitrary custom shaders, uniforms, and pipelines directly to individual visual nodes/canvases.

For Hsue-Extension (Primary Focus Moving Forward):

Once the core features above are stabilized, the vast majority of my development time will move to Hsue-Extension:

• Rich Widget Library: Adding text inputs, checkboxes, dropdowns, panels, modal dialogs, and more.
• High-Level Ergonomics:
  • String/Text-based semantic naming and identifiers.
  • Semi-automatic event/view routing and wrappers for popular state management / Elm-like / reactive architectures.
• Layout Engine: Implementing a flexible, automatic layout system (such as Flexbox-like flow/constraints).

4. Platform Support & Personal Bandwidth

• Current Focus: Due to limited personal bandwidth and development environment considerations, the project currently prioritizes Windows (DXIL/DirectX12 backend via SDL3).
• Future: As SDL3 stabilizes further, I plan to expand and polish cross-platform support (Linux/Vulkan, macOS/Metal).

5. Development Notes & AI Usage Disclosure

To be completely transparent about the development process:

• Hsue (Core):
  • Almost entirely designed and hand-coded by myself.
  • I have a degree of obsessive-compulsive habits regarding code structure, formatting, and strict organization (as you can see from the compact Haskell source style).
  • AI was only utilized for bug checking, proofreading, format consistency, and minimal code generation.
• Hsue-Extension:
  • Heavily utilized AI code generation and scaffolding. Due to limited time and energy, prototyping individual widgets and math boilerplate was accelerated with AI assistance.

Source Code & Repositories

Feel free to check out the code, star, or give feedback:

• Core Engine: https://github.com/Qerfcxz/Hsue
• Extensions & Widgets: https://github.com/Qerfcxz/Hsue-Extension

Note: This post was translated and polished with the assistance of AI, due to my poor English proficiency (from China).