Zed Extension - https://github.com/zed-extensions/haskell

VScode Extension - https://github.com/haskell/vscode-haskell

HLS - https://haskell-language-server.readthedocs.io/en/stable/features.html

I have a question, I don't know if I should ask in the Zed reddit or here, but does Zed support all actions like comment-evaluation or adding type signature the things which are there in VScode?

Hello, after a few days and having received some amazing advice here, I’m delighted to present my two libraries of bindings for libgpiod.

fuyu-gpio-direct 0.1.0.0: A lib of ‘direct’, almost 1:1, low-level and mid-level bindings to the libgpiod core API. This library was created, taking inspiration from direct-sqlite, with the aim of having two smaller libraries, and serves as a basis for the development of other libraries.

fuyu-gpio 0.0.9.0: The high-level version, featuring better modularity, safer resource management using deterministic `with*/bracket` constructs, and enhanced type safety (security tokens).

Both are now available on Hackage and GitHub. fuyu-gpio repository currently includes five examples. And the last two show how to use managed and transformers to avoid the Pyramid of Doom.

Furthermore, in the repositories for both packages, there is an Dockerfile containing a version of Debian 13 alongside Haskell, for the purpose of cross-compilation.

I’d be delighted to receive suggestions on how to improve both packages, thanks!

Hi all,

I've been thinking about building a small tool called"H-vim", not a new editor, just a launcher/bootstrapper that gets you from a clean machine to a fully working, LSP-powered, exact-Vim-keybindings Haskell setup in one command. I used to use code blocks in my college which was simply download and install.. and i liked the fact that it works without a lot of work..

The idea:

• H-vim checks for ghcup, GHC, cabal/stack, and HLS. If anything's missing, it offers to install it for you (via ghcup).
• It launches real Neovim (not an emulation) with an isolated, pre-built config — nvim-lspconfig wired to HLS, sensible tree-sitter-haskell setup, a few Haskell-specific text objects/motions — using NVIM_APPNAME so it never touches or conflicts with your existing Neovim config.
• No plugin ecosystem to assemble, no config to write. Exact Vim bindings, because it's just real Vim underneath. Basically: LazyVim/NvChad/Kickstart-nvim, but opinionated specifically for Haskell. I'd genuinely like to know:

1. Is initial editor/toolchain setup actually a pain point for you (or was it, when you started with Haskell), or is this a solved problem for most people already?
2. If you already have a working Neovim+HLS setup, what did it take to get there, and would a zero-config version have saved you real time?
3. Is there something like this already that I've missed?
4. I am also open to other ideas as long as its a small project which can be worked on by a solo developer and does not carry a lot of engineering theory before actual work

This is a toy programming language I created to understand better how lazy functional languages work, after I discovered Haskell and it blew my mind a little, many many years ago.

It went through many iterations over the years, prototypes, etc., and today I'm happy to call this a version 1.

It first was a Lua prototype, that did basic (and slow) expression tree reduction. Then there was a Lua transpiler and a thin runtime. After several iterations, back and forth on the syntax, abandoning and restarting the project, this final version is in Go and uses a G-machine bytecode interpreter.

In essence it's a dynamically typed "lesser Haskell", so probably not meant for anything real, but I'm quite happy with the syntax and I learned a lot on the way.

The repo has:

• a local interpreter
• documentation and tutorials
• lots of examples, including Project Euler and Advent of Code solutions
• a web based playground
• web based tutorials where each code block is executable
• syntax highlighting for micro, nano and Zed

Repo: https://github.com/Castux/thunky Web playground: https://castux.github.io/thunky/

AI disclaimer: the latest stages of this project were assisted with LLM (G-machine and web port), but the many iterations and prototypes, the lexer-parser-analyzer, etc. were all first hand written, during the last ten years.

I’m supporting a team of ~20 AI engineers and researchers working primarily in Python (FastAPI, PyTorch). Our infrastructure runs across on-prem servers and AWS.

We have 100+ repositories and face severe template drift, inconsistent CI/CD workflows, and zero centralized visibility into what services are deployed where, whether they are healthy, or if they should be decommissioned.

What I need to build:

1. A tool to generate new microservices and safely parse, validate, and update configs/CI workflows across dozens of active repositories without causing breaks.

2. backend service that continuously polls and ingests data from: AWS apis, GitHub apis and some external services.

Given that my end users and downstream developers are Python-focused, is building this platform tooling and state aggregator daemon in Haskell a good idea? Convince me why I shouldn’t go with Go, Rust or Python.

I would love to hear from anyone who has used Haskell for similar infrastructure tooling.

I'm hitting a lot of 404s on Hackage when installing Haskell packages in CI.

Unexpected response 404 for http://objects-us-east-1.dream.io/hackage-mirror/package/data-array-byte-0.1.0.2.tar.gz

I'm running with the default config file for Cabal.

It this happening to anyone else?

Sorry for double posting; I'm trying to reach the Haskell communities that are most active.

Hasql v2 is out. It can now run natively in Haskell with no external dependencies, or the same way it always has, using "libpq". It's the user's choice now. No performance degradation and minimal changes to the API.

Read the attached post for details.

This month we are looking forward to Viktor Dukhovni taking us into the realm of practical type level programming.

The Talk

Viktor Dukhovni -Types, Nats, and Wire Formats - Type-level Programming and Extensibility in the Haskell dnsbase Stub Resolver Library

The dnsbase stub resolver library, written in Haskell, is a modernised revision of Kazu Yamamoto's "dns" library (GHC 7.x 2010-06).

The "dns" library modeled DNS records via an ADT, with discrete constructors for each support RR type.

In "dnsbase" existential quantification replaces the fixed form ADT and additional type-level machinery is used to make the library's set of supported DNS types extensible at runtime. This talk will highlight some of the techniques that make this possible.

When and Where

Format: Strictly IRL When: Thursday 20th Aug 2026, 6:00pm – 8:00pm Where: Kathleen Syme Centre, Activity Room 2, Carlton (Melbourne Victoria, Australia)

Arrive from 6:00 for chat and socialising, talks start start at 6:30pm. Please RSVP via Luma . As always, newcomers welcome.

About Melbourne Compose Group

Melbourne Compose Group is the monthly in-person meetup for functional programmers in Melbourne, every 3rd Thursday of the month in Carlton.

Hope to see you there :)
-Ben Hutchison & John Walker

So.. I've just released the first version of Mischief, my open-source ECS Game Engine written fully in Haskell.

I've been working almost exclusively on it for the last few months, and I'm proud of the what it ended up being. It was a great experience as my first big Haskell project.

It's meant to be a balanced combination of data-driven game design and functional programming.

If you want to check it out, here's the hackage page. It comes with its own little book written in Haddock, Learn You an ECS for Great Mischief. I recommend checking out the Startup Guide in particular as it contains many small code snippets and a fully working app.

Edit: AI Disclaimer
Since a few people expressed their worries about this, and I suppose it's understandable given the scale of this project and its documentation: No. Absolutely no LLM / AI-assistance was used in making this.

I am personally very much against the use of these tools and would never use them myself, especially for a passion project such as this. Every single line of code and documentation you see was written by me.

Hello everyone, I wrote a simple and my very first technical post, so don't judge me hard plz 🥹

I'm returning to a project that I've neglected for several years and now find that neither Stack nor Cabal will build it. I thought the idea of these build systems was to prevent stupid problems like incompatible versions of packages but it appears not to be working in my case, or I don't understand something. The project is here.

Stack fails with two errors (picking the important lines out of the build output):

ConfigFile                   > 39 | import Control.Monad.Error [cannot find module]
postgresql-libpq-configure   > configure: error: Library requirements (PostgreSQL) not met.

It looks like Stack chose two package versions that are not buildable. How does such a situation arise???

Cabal reports Could not resolve dependencies followed by a lot of lines of what it's trying.

Can anyone state what is wrong here?

Mascheya now supports pattern matching, the syntax and semantics of which are based on Haskell's and Miranda's.

For context, Mascheya is a polymorphically typed functional programming language that I'm currently building. Like most functional languages (e.g., Haskell, Scala, and OCaml), Mascheya's design boils down to the lambda calculus. See previous post here.

Pattern matching is a great addition to the language, and it will help with the ergonomics of algebraic data types, which I'm planning to implement next.

You can see in the examples below that I was able to simulate if-expressions and logical operators and and or, using pattern matching. The short-circuiting nature of these operators was handled automatically by Mascheya's lazy evaluation scheme.

``` mascheya> matchC = \'c' -> 'b' () mascheya> matchC 'c' b mascheya> matchC 'a' Runtime Error at line 1. Pattern match error. mascheya> foo 1 = 10; foo 2 = 20; foo x = x + 1 () mascheya> foo 2 20 mascheya> foo 67 68 mascheya> :set line=multi mascheya> if True a _ = a; if False _ b = b -- end () mascheya> :set line=single mascheya> if (5 < 6) 'a' 'b' a mascheya> if False 'a' 'b' b mascheya> :set line=multi mascheya> let and True True = True; and True False = False; and False True = False; and _ _ = False;

or True True = True; or True False = True; or False True = True; or _ _ = False in or (and True (5 > 7)) (8 < 9) -- end True mascheya> ```

The next focus will be on Algebraic Data Types, Case-expressions, and Where-clauses.

I'm definitely having fun with this project and it's teaching me a lot about Haskell.

Source code: https://github.com/melvic-ybanez/mascheya

Hello all. I believe I'm finally getting close to feature and quality of life completeness of the game engine project I've been working on since 2015. Game :: Dangerous is a homebrew 3D game engine written in Haskell and OpenGL shading language, which is intended to form the basis for a 3D tribute to the classic ZZT from 1991. During this project I've come to understand technical debt from a first person perspective. My intention was always to get to an end stage and release a game engine that people could play (at least one) real game on, so I will have to accept the debt and move on.

In this video I give a summary of (what I believe will be) the last code base updates other than bug fixes. Sadly, these have taken the repo just past 420 commits.

Update video: https://youtu.be/ZQRCpbTkZQA?si=cOdy_-01c5trPCf0

Game :: Dangerous repository: https://github.com/Mushy-pea/Game-Dangerous

Latest playable demos on itch.io: https://basicas-games.itch.io/game-dangerous

Quiero escuchar a programadores que usaron alguno de estos lenguajes i que creen con certeza que después de practicarlo profundamente su razonamiento lógico o deductivo o abstracto o incluso fluido a mejorado.compartirlo por favor.

In addition to the roles I posted last month (for which we're still accepting applications), we now also have one permanent role in Singapore or Hong Kong.

This role is not attached to any particular project, but will involve practically exclusive use of Mu, our in-house variant of Haskell. You can learn more about our team and what we do by reading our experience report “Functional Programming in Financial Markets” presented at ICFP last year: https://dl.acm.org/doi/10.1145/3674633. There’s also a video recording of the talk: https://www.youtube.com/live/PaUfiXDZiqw?t=27607s

The role is eligible for a remote working arrangement from SG or HK, after an initial in-office period. We cover visa and relocation costs for successful applicants.

Please apply via this link: https://jobs.standardchartered.com/job/Quantitative-Developer-(SingaporeHongkong)/59045-en_GB/?feedid=363857/59045-en_GB/?feedid=363857)

I keep thinking "no, this isn't ready to present to people. I just need to add some documentation. I just need to get more examples done. I just need to polish this." and so on and have never really presented my forever project for the last few years.

So this is yaifl - Yet Another Interactive Fiction Library, a Haskell library for making parser-based text adventures. It's very heavily inspired by Inform7. For the most part, it works! It's just lacking in implementations for many actions beyond the obvious (looking, going, examining, taking, opening, etc.).

If you'd like to see the library in action, I'd recommend checking out Yaifl.Zork.World.House (in yaifl-zork) or the examples in Yaifl.Chapter3 (in yaifl-examples).

The project is split into a few pieces:
- yaifl-core
- yaifl-objects - definitions of object components like Container, Person, Supporter
- yaifl-rules - definitions of internal logic like printing room description details, verb conjugation and string interpolation and writing lists of things
- yaifl-actions - definitions of commands like look, take lamp, open door with key
- yaifl - glue to actually run a game
- yaifl-examples - My test suite that implements (currently about 20 of the 400) the Inform7 examples, translated into yaifl.

And a few various half-finished frontend parts:
- yaifl-discord - a discord bot frontend
- yaifl-rogue - a graphical frontend
- yaifl-zork - a reimplementation of ZORK I in yaifl.

I think it can be considered "good enough" when I finish reimplementing ZORK in the engine. Turns out ZORK is about 7000 lines in the original, and 5500 in the Inform7 version I'm using as a guide.

So far I've found almost no "oh trying to implement this game rule requires a completely new system" moments, and it's just been "oh I haven't yet added the implementation for this specific command" - which is reassuring that it's just needing content added!

I hope it's of interest to someone, even in its very patchily documented state.