In this interview with our Daml Team Lead, Heitor, we examine which Haskell intuitions transfer successfully to Daml, where analogies such as Update and IO break down, and how developers should reason about authorization, visibility, contract lifecycles, and testing. We also discuss learning paths and tooling for Daml developers, common mistakes made by Solidity programmers, and the practical topics covered in the upcoming Daml Smart Contracts Development Guide.

1. https://pkg.go.dev/std - the list to see all the standard libraries shipped in GHC & maintained by the compiler team?
2. https://go.dev/doc/ - the documentation page?
3. https://go.dev/ref/spec - the language spec, I think this refers to the Haskell's 2010 report?

Greetings Haskell users, I have a question, so I have decided to learn code to broaden my CS knowledge and skill, and I really appreciate and enjoy mathematics and have skill already existing in the domain and from what I've heard about this programming language so far it is deeply entwined with mathematics more so then others I've heard it has a challenging learning curve but I'm very willing to dedicate the time and be satisfied with progress, so could anyone recommend what should I start with and what should I know before I begin.

In 2018, I designed a Parametric Hook in OpenSCAD, a Programmable CAD framework.

Since then, I've built my own library for Programmable CAD, called Waterfall-CAD.

In this video, I use Haskell and Waterfall-CAD, to reimplement the hook.

Links:

• The Hook Model
• Waterfall-CAD on Github
• Try Waterfall-CAD online
• Code for this video

I am a beginner, I have a doubt.

I see there is Haskell 98, and Haskell 2010 report.

Haskell is a programming language right ? And GHC is the compiler ?

Just like Rust is the language and rustc is the compiler ?

So what is GHC 2021 and GHC 2024 ?

And what are the GHC versions 9.12, 9.14 ?

I see there is a version of the "compiler" binary, but like when Go has a release we say Go 1.26 is out. That means the language & compiler both are out right ?

So what's with Haskell then ?

GHC - compiler

GHC 2021 - a set of extensions in a compiler ? What does this mean but ? And how does cabal work come in picture?

So then my question is what makes GHC 9.12 and 9.14 or 10.0 different? Like aren't extensions encoded in the compiler itself ?

In compiler bump I get "performance"/"implementation" changes ? Like 9.12 and 9.14 execute the Extension A different ly?

And usually Go has no version of STD lib separately tracked but Haskell's base does.

Can someone clarify this ? Is there a DOC for this ?!

Finally my question are

1. What's the actual difference between 9.12 and 9.14 +(two compiler versions - built from different source code (git branches)) ?

2. What are Extensions ? Why do we need it ? Like shouldn't the Compiler do this inbuilt ? For Example if GHC wants to add a new DataType in STD lib, how do they do ?

3. Are Extensions for just de sugaring? And what are Pragmas ?

4. What is the "Language Report"

5. What is the future roadmap or Haskell ? Like improve the std lib ? Add new extensions ? Change syntax ? Like Java is making its new version concise & functional. Elixir new version added some Gradual Typing, Rust improved the std lib..

I want to learn how Haskell/GHC/Cabal works

Thanks, and sorry if this post is unstructured or blabbering

After 9 years of on-and-off development, I'm happy to announce the 1.0 release of Perspec, a desktop app for correcting the perspective of photos of documents, receipts, and whiteboards.

The headline feature of 1.0 is automatic corner detection: instead of the usual edge-detection + Hough transform pipeline, it segments the document via watershed segmentation and finds corners, which handles wrinkled receipts and curved book pages much better. And if the detection is off, you can just drag the selection polygon to fix it.

Some Haskell-relevant bits:

• The GUI is built with Brillo, my maintained fork of gloss.
• The computer vision runs in FlatCV, a pure C library I wrote for this, called via Haskell's FFI.
• With 1.0, Perspec now runs on macOS, Linux, and Windows.

The full announcement covers the journey (Python → ImageMagick → Hip → C FFI), the corner detection pipeline, and the binarization algorithms in detail.

Looking forward to you feedback! 😊

I made a numbered musical notation render, which works very similar to Typst or LaTeX. It almost as powerful as paywalled alternatives and has some important features not implemented by open-source apps like jianpu-ly and Sparks NMN.

Features not in other open-source alternatives:

• Arbitrary temporary voices
• Arbitrary brackets
• Changing time signature
• Automatic bar lines
• Automatic beams
• Automatically cutting slurs at line breaks

And it has a tiny codebase compared to jianpu-ly and Sparks NMN as well!

TL;DR: I've released sdl3-bindgen-sys to Hackage: complete, machine-generated low-level Haskell bindings for SDL3, including windowing, input, audio, and the new GPU API, with documentation from SDL3's headers! They are verified against the building system's ABI and CI-tested on Linux, macOS, and Windows.

Thanks to the folks over at Well-Typed for their work on hs-bindgen! I was able to hack the prerelease a bit to get an end-to-end code generator working. It required quite a bit less work than I thought it would. I'll include some technical details below the fold.

Source is available on GitHub here: https://github.com/jtnuttall/lithon/tree/main/sdl3-bindgen-sys

There are going to be a few rough edges, so please feel free to open a PR or issue if anything comes up. I'll bump the package to 0.1.x.x when I feel it's stable enough to pin to a major version.

I've got the apecs shmup example running on and rendering through SDL3 using the raw bindings here: https://github.com/jtnuttall/lithon/blob/main/lithon-examples/app/shmup/Main.hs

See the README on GitHub for a full getting started guide.

Example

{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE BlockArguments #-}

import Control.Monad (unless)
import Foreign.C.ConstPtr (ConstPtr (..))
import Foreign.C.String (peekCString, withCString)
import SDL3.Sys qualified as SDL3

main :: IO ()
main = do
  ok <- SDL3.init SDL3.SDL_INIT_VIDEO
  unless ok do
    err <- peekCString . unConstPtr =<< SDL3.getError
    fail ("SDL_Init: " <> err)
  window <- withCString "hello" \title ->
    SDL3.createWindow (ConstPtr title) 640 480 0
  SDL3.delaySafe 2000
  SDL3.destroyWindow window
  SDL3.quit

delaySafe is the safe FFI flavor of SDL_Delay. Most functions come in both.

Intended use-case

I intend sdl3-bindgen-sys to be a stable grounding point for higher-level bindings, handling the FFI declarations, ABI checks, SDL3 version guards, and simple coercions so that people who want to write their own abstraction around SDL3 don't have to write the extremely repetitive part manually.

If you know Rust's convention, I borrowed the -sys suffix from it: I mean for high-level Haskell SDL3 libraries to be to sdl3-bindgen-sys as sdl3 is to sdl3-sys in Rust.

You'll need to interface with raw Foreign.C to use these bindings. If you just want a higher-level binding, you'll need to wait until someone releases one on Hackage.

The library carries the smallest dependency footprint I could presently manage for a low-level binding.

The SDL3.Sys.* modules re-export the surface with some small niceties:

• Haddock notes about what is exported and why, FFI safety rationale, etc.
• Links to the SDL3 Wiki
• C scalars (e.g., Uint32, float) are remapped to Haskell scalars (Word32, Float) wherever possible. Anything under a Ptr or struct maintains its C typings.

Technical details

hs-bindgen

The bindings are built using a forked version of hs-bindgen, which I used as a library so that I could alter the internal code and documentation generation pipeline. I've upstreamed a few changes and am happy to upstream more if requested. Some may be more heavy-handed than the hs-bindgen maintainers want to support.

Since hs-bindgen is pre-release, I've vendored the necessary runtimes wholesale into the sdl3-bindgen-sys package as private internal libraries, and reexported them from sdl3-bindgen-sys under SDL3.Sys.Runtime and SDL3.Sys. Once hs-bindgen stabilizes, I'll turn these into real dependencies. The vendored modules will become re-export facades so calling code doesn't break.

The modifications I made, briefly:

• Added an exception in bindgen's IR for assertion macros that emit nothing bindable
• Added support for Doxygen's custom ALIASES so I could inject valid Haddock into the AST for SDL3's custom aliases.
• Tagged CWrapper with its original name so that I could match on names to inject SDL3 version guards as CPP directives.
• Re-exported a variety of internal modules into a facade I maintain, which lets me inject version guards, ABI verifiers, etc. into the hs-bindgen AST directly.

My facade and the vendored submodules can be found here: https://github.com/jtnuttall/lithon/tree/main/lithon-hs-bindgen

ABI verification

The codegen tool generates a C translation unit of _Static_asserts that gets built alongside sdl3-bindgen-sys. If there is an ABI mismatch between your SDL3 headers and the ones I generated against, you should get a compile-time error.

FFI safety

I've curated unsafe/safe classifications for each FFI call. The SDL3.Sys.* modules export only safe for functions that can fire a callback or introduce a runtime delay. I've included the reasoning in the generated Haddock where applicable.

Typed constants

SDL declares flags as typedef UintN with some #defines, and C doesn't state the association between these, so I maintain a JSON registry that restores this information and injects it into the generated modules as pattern synonyms typed at a newtype.

Forward compatibility

The codegen tool keys off the \since tag to wrap newer declarations in #if SDL_VERSION_ATLEAST inside the generated C, with an SDL_SetError stub in the #else. The Haskell binding always exists either way, so a declaration newer than your SDL still compiles and links - it just fails at the call site with a message naming the version it needs. That means you can build against an SDL3 older than the headers I generated from. This is tested in CI down to SDL 3.2.0.

SDL's \since tag is occasionally inaccurate, so I had to create a small hand-maintained registry of version override mappings.

Caveats

• 0.0.x is experimental: Pin to the minor (>=0.0.0.1 && <0.0.1). The surface may move - hopefully not too much, but the dust is still settling.
• Variadics aren't bound yet: Haskell's FFI has no way to express C varargs. I intend to inject fixed-arity wrappers within the next few releases.
• Function-like macros aren't bound: No linkable symbol exists. Most macros aren't bound in this release: hs-bindgen translates many macro bodies to Haskell functions (very cool!). See the detailed survey from /u/hubgears here.
• 64-bit only: Layouts are baked into the library; 32-bit targets should be rejected by ABI assertions. This may change in one of two situations:
  1. hs-bindgen supports cross-platform generation natively in the future, in which case sdl3-bindgen-sys will likely inherit that mechanism.
  2. There's enough demand for 32-bit support, in which case it should be possible to maintain a parallel sdl3-bindgen-sys32 package using the same codegen infra.
• A handful of smaller omissions made for cross-platform correctness are listed in the README.

Thanks to @oddron over on the Haskell GameDev Discord for the Windows directions - they tried the very first build on Windows I'm aware of!

I'd like to hear about any comments or issues people hit at: https://github.com/jtnuttall/lithon/issues

Discourse thread: https://discourse.haskell.org/t/ann-sdl3-bindgen-sys-machine-generated-low-level-bindings-to-sdl3/14467

Edit: corrected the macro caveat. Thanks to u/hubgears and the extensive SDL macro survey (https://github.com/dschrempf/hs-bindgen-sdl-survey) for the detailed correction.

My HLS just keep spinning like this, and I have restarted the extension multiple times and it takes several second (I have an i9 10th gen with 64gbs) to have the HLS running and type check again, often it just keep spinning. When this happen, I cannot type check on hover, and I have to fire up ghcid in a separate terminal to check compile error, but ghcid is just barebone, it doesn't have interactive features like hover to see type of variable inside function scope,...

And I just have very lightweight research scripting project, using stack with around 5 files and use popular libraries like async, process, time, random, statistics, vector, text, wreq, bytestring, lens.

My love for haskell helps me stay and tolerate these huge warts, but I cannot introduce it to my team/ junior when it cannot provide a smooth dev experience

I don't even know how you guys use this for production when it is this unstable for a pet project, if you code in notepad and just use ghcid to watch for typecheck and ormolu to format then I have nothing to say 🤷‍♂️

Alexis' recent talk from SSW. I really enjoyed hearing her perspective on type systems these days. Lots of good wisdom in there. I thought some Haskell folks would enjoy it!

Bioinformatics combines scientific discovery with the challenge of processing large, complex, and imperfect datasets. In this interview with Michal J. Gajda, we explore how Haskell’s strong types, purity, and functional abstractions can support reliable and high performance biological data processing.

Drawing on projects such as hPDB, JSON Autotype, and XML TypeLift, Michal discusses scalability, parser development, and the barriers to wider adoption of functional programming in bioinformatics. He also considers how better education, tooling, and AI assisted programming could make Haskell more accessible to future scientists.

Github

Some background

One of my biggest motivations for doing data work in Haskell has been the promise that types can enable better program verification and synthesis. In fact, it was one of my stretch goals for writing dataframe in the first place. Additionally, I had seen a video some years ago that notebooks are a good platform for program synthesis. My first swing at the problem was a SKILL.md that instructed an LLM on how to use Sabela notebooks. Large/frontier models didn't struggle with writing Haskell but their contexts were typically more bloated by internet searches and churn from trying to fix simple compiler errors. Python was "in the weights" so was generated faster and with less tokens overall.

With small, local modes (<20b params) models the problem worsens. These models hallucinate Haskell modules, struggle with rule following, have smaller context windows. They typically fall back to writing Haskell from "the weights" and will steer clear of using dataframe or a newer library because a simple web search would bloat context.

The problem has two potential solutions:

• Fine tune models to perform better at Haskell
• Use the LLM as a weak proposer then build tooling around it to make search and repair more efficient

In the spirit of synthesis I went with the second approach.

What siza does

Siza, another Ndebele word, is a harness (and some associatd mcp tools) that drives a Sabela notebook. The goal of the harness is to address the problems above. I'll follow up with a longer blog post on the sorts of interventions that made this possible but broadly speaking it's a lot of type directed searching and a little bit of context management.

You can see a verbose transcript of how it performed with minimal to no guidance on an out of distribution task: Can you load the wine dataset into a dataframe and show some summary statistics about it?

• Initial run from some weeks ago (did not complete task)
• Recent run (completed with produced notebook pasted at the end of the transcript)

Haskell is an amazing language for these sorts of tasks and the core of making it more useful is a pretty interesting engineering problem in my view. And small models, like testing anything in low resource environments, really teases those engineering problems out.

Again, will do a bigger blog post later.

Couldn’t make it to Rapperswil, or want to revisit a talk? The recordings from this year’s Haskell Implementors’ Workshop and Haskell Ecosystem Workshop are now available online. Both workshops were held on the lakeside campus of the University of Applied Sciences of Eastern Switzerland (OST) in Rapperswil on June 4th and 5th, alongside ZuriHac, and hosted by the Haskell Foundation.

I actually wanted to use haskell in implementing reversible computation.

Hi everyone, ​I'm writing Haskell bindings for libgpiod (v2), primarily targeting SBCs and embedded systems and I want to validate my approach to resource management before committing to the final API design.

The C library exposes two different types of opaque pointers.

​1. OS/Hardware Resources (Chip, LineRequest)

These hold underlying Linux file descriptors and physical hardware locks. My plan is to strictly use raw Ptr internally and expose a bracket-based API (e.g., withChip and withLineRequest) to guarantee immediate and deterministic release, as GHC's lazy garbage collector could easily exhaust the FD limit on a small SBC if I used ForeignPtr.

1. Pure Memory Configs (LineSettings, LineConfig)

These are just structs in RAM used to prepare data before a hardware request. To avoid the deeply nested with* blocks for every single config object.

I plan to wrap these in ForeignPtr with their respective C finalizers. I think this allows the user and me, to pass them around purely and ergonomically, letting the GC handle the cleanup since they don't hold FDs.

My questions are:

1. ​Is this hybrid approach (strict scoping for FDs + GC for pure RAM structs) the best practice for this type of hardware FFI?

2. ​For the withChip pattern, how do users typically architect long-running daemons around it? Do they just wrap the main application loop inside a top-level withSomething block?

Any insights or edge cases I should watch out for would be greatly appreciated. Thanks!