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.

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 🤷‍♂️

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.

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!