Hashtag

#Haskell

1,981 posts tagged with this hashtag.

@dougmerritt@mathstodon.xyz

I haven't watched this yet, but it looks like an interesting analysis:

> Why Do Companies Stop Using Haskell? | Vaibhav Sagar | ZuriHac 2026
>
> OST – Ostschweizer Fachhochschule
> 2,835 views Sep 11, 2026
>
> Why do companies stop using Haskell, even when the language itself works well? Vaibhav Sagar examines real-world cases to uncover the business, organizational, and technical forces that can push companies away from Haskell.
>
> The talk begins by examining Haskell's unique position in the software industry. While Haskell has proven itself capable of supporting successful businesses, it remains neither a mainstream technology nor the industry's newest trend. This creates a situation where failures are often attributed to the language itself, even when broader business forces are responsible. Sagar contrasts characteristics of the Haskell ecosystem with common business priorities such as profit maximization, short-term incentives, and the systematic undervaluation of maintenance work.
>
> Through a series of recurring patterns, he analyzes how Haskell projects can end. These include large-scale rewrites, second-system effects, failed experiments, vanity projects, funding challenges, acquisitions, leadership changes, technology-fashion cycles, overly complex codebases, and infrastructure limitations. Along the way, he connects these stories to broader software engineering concepts such as technical debt, process improvement, organizational incentives, and long-term maintainability.

youtube.com/watch?v=2PebXEak24M

youtube.com

Why Do Companies Stop Using Haskell? | Vaibhav Sagar | ZuriHac 2026

Why do companies stop using Haskell, even when the language itself works well? Vaibhav Sagar examines real-world cases to uncover the business, organizationa...

@dougmerritt@mathstodon.xyz

I haven't watched this yet, but it looks like an interesting analysis:

> Why Do Companies Stop Using Haskell? | Vaibhav Sagar | ZuriHac 2026
>
> OST – Ostschweizer Fachhochschule
> 2,835 views Sep 11, 2026
>
> Why do companies stop using Haskell, even when the language itself works well? Vaibhav Sagar examines real-world cases to uncover the business, organizational, and technical forces that can push companies away from Haskell.
>
> The talk begins by examining Haskell's unique position in the software industry. While Haskell has proven itself capable of supporting successful businesses, it remains neither a mainstream technology nor the industry's newest trend. This creates a situation where failures are often attributed to the language itself, even when broader business forces are responsible. Sagar contrasts characteristics of the Haskell ecosystem with common business priorities such as profit maximization, short-term incentives, and the systematic undervaluation of maintenance work.
>
> Through a series of recurring patterns, he analyzes how Haskell projects can end. These include large-scale rewrites, second-system effects, failed experiments, vanity projects, funding challenges, acquisitions, leadership changes, technology-fashion cycles, overly complex codebases, and infrastructure limitations. Along the way, he connects these stories to broader software engineering concepts such as technical debt, process improvement, organizational incentives, and long-term maintainability.

youtube.com/watch?v=2PebXEak24M

youtube.com

Why Do Companies Stop Using Haskell? | Vaibhav Sagar | ZuriHac 2026

Why do companies stop using Haskell, even when the language itself works well? Vaibhav Sagar examines real-world cases to uncover the business, organizationa...

@DiazCarrete@hachyderm.io
@peterb@mathstodon.xyz

As part of boot-strapping my NES emulator, I port my 6502 CPU emulator from to . Some architectural changes – some encouraged by the language, and others simply from having a second bite at the apple – are made.

Thumbnail painting: La Bohémienne Endormie (1897) by Henri Rousseau

youtube.com/watch?v=li1DR392vv4

youtube.com

NES Emulator in Lean - Porting the CPU

As part of bootstrapping the NES emulator, I port my 6502 CPU emulator from Haskell to Lean. Along the way I make some architectural changes - some encourage...

@peterb@mathstodon.xyz

As part of boot-strapping my NES emulator, I port my 6502 CPU emulator from to . Some architectural changes – some encouraged by the language, and others simply from having a second bite at the apple – are made.

Thumbnail painting: La Bohémienne Endormie (1897) by Henri Rousseau

youtube.com/watch?v=li1DR392vv4

youtube.com

NES Emulator in Lean - Porting the CPU

As part of bootstrapping the NES emulator, I port my 6502 CPU emulator from Haskell to Lean. Along the way I make some architectural changes - some encourage...

@dfortes@mastodon.social

It's sad that Haskell and OCaml are stuck with such terrible tooling / build systems. I'm partial to OCaml but opam + dune are terrible, and FFI is too complicated (Ocaml LSP is amazing though).

If OCaml had better tooling I would use it instead of Rust whenever possible. As is its I'm probably giving it up for now.

@marcosh@functional.cafe

is there any command line option equivalent to `:set +s` and `:set +t` in `ghci` ?

@DiazCarrete@hachyderm.io
@lobsters@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@nmeum@chaos.social

I just released the first version of Qute, a Haskell-based software analysis framework for programs represented in the QBE intermediate representation. Qute provides a modular interpreter for the QBE specification and then implements software analysis techniques (mainly symbolic execution) on top of that.

For further information, see the announcement mail.

lists.sr.ht/~mpu/qbe/%3C38XOXB

@nmeum@chaos.social

I just released the first version of Qute, a Haskell-based software analysis framework for programs represented in the QBE intermediate representation. Qute provides a modular interpreter for the QBE specification and then implements software analysis techniques (mainly symbolic execution) on top of that.

For further information, see the announcement mail.

lists.sr.ht/~mpu/qbe/%3C38XOXB

@pmidden@fosstodon.org

I've been writing pseudo "hell"[1] shell scripts for a while now. The ability to easily add command-line options and the simplicity of the language is refreshing. And almost everything is better than bash.

Error messages are abysmal, and a bigger stdlib would be great, but nowhere does it say it's complete or ready yet, sothat's fine.

[1] github.com/chrisdone/hell

github.com

GitHub - chrisdone/hell: Haskell-based shell scripting language

Haskell-based shell scripting language. Contribute to chrisdone/hell development by creating an account on GitHub.

@pmidden@fosstodon.org

I've been writing pseudo "hell"[1] shell scripts for a while now. The ability to easily add command-line options and the simplicity of the language is refreshing. And almost everything is better than bash.

Error messages are abysmal, and a bigger stdlib would be great, but nowhere does it say it's complete or ready yet, sothat's fine.

[1] github.com/chrisdone/hell

github.com

GitHub - chrisdone/hell: Haskell-based shell scripting language

Haskell-based shell scripting language. Contribute to chrisdone/hell development by creating an account on GitHub.

@Jose_A_Alonso@mathstodon.xyz
@lobsters@mastodon.social
@haskell@fosstodon.org

Does *your* runtime system embed the Eye of Sauron? Yeah, I didn't think so. 💅

Description of selector thunks in the GHC runtime system, and suddenly the sentence "the garbage collector sees all, knows all."
ALT text

Description of selector thunks in the GHC runtime system, and suddenly the sentence "the garbage collector sees all, knows all."

@haskell@fosstodon.org

Does *your* runtime system embed the Eye of Sauron? Yeah, I didn't think so. 💅

Description of selector thunks in the GHC runtime system, and suddenly the sentence "the garbage collector sees all, knows all."
ALT text

Description of selector thunks in the GHC runtime system, and suddenly the sentence "the garbage collector sees all, knows all."

@Jose_A_Alonso@mathstodon.xyz
@lobsters@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@aartaka@merveilles.town

Wondering if I should make a Hoogle alternative, but for . index.scheme.org has an exhaustively typed listing of most SRFIs and all of the standard. Might it be useful? Types are documented, but something like type variables and dependent types are missing, so there’s not much complexity and richness to the system…

Shchmoogle?

@haskell@fosstodon.org
@lobsters@mastodon.social

blog.jle.im

"Five-Point Haskell": Unconditional Election (via Parametricity)

Welcome back to Five-Point Haskell! This is my attempt to codify principles of writing robust, maintainable, correct, clear, and effective code in Haskell and to dispel common bad practices (or, heresies) I have run into in my time. In the last post, we talked about Total Depravity, which is about treating any mentally tracked constraint or condition as inevitably leading to a catastrophe and denouncing the reliance on our flawed mental context windows. However, stopping here gives us an incomplete picture. Firstly, types aren’t just about preventing bad behaviors. They’re about designing good code. Secondly, there is only so much you can do by picking careful structures and making invalid states unrepresentable. These are still human tools with human flaws. The next point, to me, is about an aspect of the type system that I see little coverage of, but is a doctrine of design that I reach for in almost everything I write. It’s about leveraging the unyielding properties of math itself to take care of our fate, even when we are unable to structure our types well. So, when writing Haskell, remember Unconditional Election. Unconditional Election: The power of the forall to elect or reprobate instantiations and implementations through parametric polymorphism. These properties aren’t based on any conditional ad-hoc aspect of types, but are truly unconditional, predestined by universal quantification.Surrender your control to parametric polymorphism in all things. Embrace the “free”-dom of “Free Theorems” from one of Haskell’s greatest unexpected strengths: the type parameter.

@Jose_A_Alonso@mathstodon.xyz
@abnv@fantastic.earth

Folks, I've done it again. I've created a new static-site generator. Actually an starter that I extracted from my website's SSG so that I can use it to build new blogs for my other projects without being bogged down with the details specific to my website. If any of you fancy writing your own SSG in , give it a go: abhin4v.github.io/shake-blog

BlogShake is meant to be forked and extended. It comes with a basic set of features: posts, pages, tags, archive and feed, which may be enough for you. But the main idea is to understand it and extend it for your website according to your requirements and taste.

It uses , and beneath, and comes with dark mode and code highlighting support. It includes a Github Action to build and publish your blog directly on Github pages with zero friction.

Try it out and let me know. Boost to make me famous.

abhin4v.github.io

BlogShake — Home

An example blog build on Shake.

@Jose_A_Alonso@mathstodon.xyz
@jaror@social.edu.nl

is considered too theoretical by many, but Bryan, Don, and John, begged to differ by writing Real World Haskell. The book was written in collaboration with over 800 online commenters and released back to the public for free.

The book was such a success that it is still read by newcomers eighteen years later, but it is starting to show its age. So, I have now converted it to markdown and started modernizing it:

codeberg.org/jaror/real-world-

@jaror@social.edu.nl

is considered too theoretical by many, but Bryan, Don, and John, begged to differ by writing Real World Haskell. The book was written in collaboration with over 800 online commenters and released back to the public for free.

The book was such a success that it is still read by newcomers eighteen years later, but it is starting to show its age. So, I have now converted it to markdown and started modernizing it:

codeberg.org/jaror/real-world-

@nmeum@chaos.social

GHC 9.14 is now available in the Alpine Linux Edge repository. This is the first-ever LTS release of the Haskell compiler and will be supported at least until late 2028, I have high hopes that it will serve us well for the next few Alpine releases.

@haskell_foundation@mastodon.social

2026 Haskell Workshop Videos Now Online

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.

haskell.foundation/news/2026-0

haskell.foundation

2026 Haskell Workshop Videos Now Online

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.

@xameer@mathstodon.xyz

I wrote a regression testing tool that diffs runtime execution states to catch silent semantic breaks. When a refactor passes unit tests but alters intermediate logic—like switching a Vec to a non-deterministic HashSet—trace-align blocks the merge in CI, proven on the jobpipe pipeline.

Code
gitlab.com/xameer/trace-align

xameer.gitlab.io/post/2026-07-

@haskman@functional.cafe
@xameer@mathstodon.xyz

I wrote a regression testing tool that diffs runtime execution states to catch silent semantic breaks. When a refactor passes unit tests but alters intermediate logic—like switching a Vec to a non-deterministic HashSet—trace-align blocks the merge in CI, proven on the jobpipe pipeline.

Code
gitlab.com/xameer/trace-align

xameer.gitlab.io/post/2026-07-

@haskman@functional.cafe
@haskell_foundation@mastodon.social

2026 Haskell Workshop Videos Now Online

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.

haskell.foundation/news/2026-0

haskell.foundation

2026 Haskell Workshop Videos Now Online

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.

@nmeum@chaos.social

GHC 9.14 is now available in the Alpine Linux Edge repository. This is the first-ever LTS release of the Haskell compiler and will be supported at least until late 2028, I have high hopes that it will serve us well for the next few Alpine releases.

@lobsters@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@CoInduction@inductive.space · Reply to Matej Cerny

First group of people: is great for slop, because slop often bad, type system catches bugs.
Second group: Haskell is bad for slop, slop good enough, type system slows slop down.

@eisfunke what about people who don't want to slop?

@abnv@fantastic.earth

Folks, I've done it again. I've created a new static-site generator. Actually an starter that I extracted from my website's SSG so that I can use it to build new blogs for my other projects without being bogged down with the details specific to my website. If any of you fancy writing your own SSG in , give it a go: abhin4v.github.io/shake-blog

BlogShake is meant to be forked and extended. It comes with a basic set of features: posts, pages, tags, archive and feed, which may be enough for you. But the main idea is to understand it and extend it for your website according to your requirements and taste.

It uses , and beneath, and comes with dark mode and code highlighting support. It includes a Github Action to build and publish your blog directly on Github pages with zero friction.

Try it out and let me know. Boost to make me famous.

abhin4v.github.io

BlogShake — Home

An example blog build on Shake.

@matejcerny@witter.cz

In case you missed it, Scarf, the analytics platform which you might know from the Sonatype integration, is moving away from . 😢

It makes me so grateful that chose a completely different, pragmatic path. With AI-ready tooling like Metals MCP, Cellar, and the TACIT project, our ecosystem is built for this new era. 🚀

avi.press/posts/2026-07-10-aft

avi.press

After 7 years in production, Scarf has reluctantly moved away from Haskell

After 7 years in production, Scarf has reluctantly moved away from Haskell

@DiazCarrete@hachyderm.io

Lightweight profiling with ghc-stack-profiler.

slide in a presentation. "Stack annotations can be left in the code! They benefit: ght-stack-profiler, haskell-debugger, IPE Backtraces, ghc-debug, eventlog-live".
ALT text

slide in a presentation. "Stack annotations can be left in the code! They benefit: ght-stack-profiler, haskell-debugger, IPE Backtraces, ghc-debug, eventlog-live".

@DiazCarrete@hachyderm.io

Lightweight profiling with ghc-stack-profiler.

slide in a presentation. "Stack annotations can be left in the code! They benefit: ght-stack-profiler, haskell-debugger, IPE Backtraces, ghc-debug, eventlog-live".
ALT text

slide in a presentation. "Stack annotations can be left in the code! They benefit: ght-stack-profiler, haskell-debugger, IPE Backtraces, ghc-debug, eventlog-live".

@armed_banana@tech.lgbt

, bitch. I'm Logan (himbo/thembo) your new favorite Haskell homosexual. Fresh handle, same menace: I torched the old account and rose from the git history like a phoenix in a clean `-Wall -Werror` build.

I write functional code, filthier commit messages, and a blog nobody asked for → thisfieldwas.green. I WILL explain monads to you unprompted and make it weird. Category theory is my love language, parser combinators are my whole personality, and yes, type systems are a little bit hot.

When I'm not bullying types into submission I'm a devoted reality TV scholar who knows exactly who deserved to win. I contain multitudes and most of them are gay.

Come for the lambdas, stay because I refactored your data pipeline and left you on read. Boost if you also gasp at a well-typed function.

Bearded man with a septum ring, undercut, and blue eyes gives deadpan in a blue hoodie beside a weathered white fire hydrant. Foggy SF street. We are both structurally load-bearing.
ALT text

Bearded man with a septum ring, undercut, and blue eyes gives deadpan in a blue hoodie beside a weathered white fire hydrant. Foggy SF street. We are both structurally load-bearing.

@haskman@functional.cafe
@haskman@functional.cafe
@DiazCarrete@hachyderm.io
@Jose_A_Alonso@mathstodon.xyz
@xameer@mathstodon.xyz · Reply to HoldMyType

I am using typeclass meta-programming to refactor my hardocode functions in , so that some old module becomes an instance of a new module
if you re , why are you using it?

@xameer@mathstodon.xyz

dependently typed programming in intrigues you, and you don’t mind staring into the sun, the singletons library provides abstractions and design patterns that can considerably cut down on the boilerplate. (Also, the accompanying paper is definitely worth a read if you’d like to go down that route.
lexi-lambda.github.io/blog/202

lexi-lambda.github.io

An introduction to typeclass metaprogramming

@mnvr@mastodon.social

so map is (a -> b) -> (f a -> f b), and_then/flat_map (a -> f b) -> (f a -> f b)

or equivalently, map is (a -> b) -> f a -> f b, and_then/flat_map is (a -> f b) -> f a -> f b, and map is fmap, and_then/flat_map is bind, but no typeclasses like , piecemeal instead)

@lobsters@mastodon.social

blog.jle.im

Extreme Haskell: Typed Expression EDSLs (Part 1)

I always say, inside every Haskeller there are two wolves, living on opposite ends of the Haskell Fancy Code Spectrum. Are you going to write “simple Haskell”, using basic GHC 2010 tools and writing universal Haskell that every introductory course offers, trying to keep the code as immediately understandable and accessible? Or are you going to pile in all of the Haskell type system and evaluation tricks you can find and turn on all the extensions, and go full fancy? In my Seven Levels of Type Safety post, I described different extremes of type safety and fancy code. I talked about how writing effective code was finding the correct compromise for the level of communication and safety you need. But this is not that kind of blog post. This is the kind of blog post where we celebrate terrifying type-safety, facetious fanciness, and masochistic meta-analysis. This series is about what happens when we dare to go full fancy. Let’s write code that is so inscrutable, so painful and torturous to write, yet so undeniably useful that you can’t help but try to throw it into every single thing you write and will feel a gnawing emptiness in your soul until you do. As our example, let’s write a type-safe method to specify your program as a series of states, with triggered transitions between them: a type-safe state machine graph using a type-safe lambda calculus. We want to specify this in a way that we can write once and then: * be interpretable in a type-safe way within Haskell. * be inspectable with visualizable control flow. * be compilable to multiple actual back-ends, letting you run the same function under multiple implementations. This exact thing is something I’ve needed and used multiple times now in projects. I want to specify one program graph within Haskell, but in a way that can compile both in C and javascript while also being visualizable and interactively explorable.

@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@mjd@mathstodon.xyz

This is the most exciting technical thing I've seen this week. Stephen Diehl has built an algebraic effects language, , that might actually be usable.

I've been excited about algebraic effects since Bauer and Pretnar's 2012 paper. Haskell's stacks of monad transformers always looked to me like a first-generation hack: yes, we have the technology that could fix the Awkward Squad, but we don't know yet what to do with it. Algebraic effects seemed like they could be the way forward.

But I tried programming in Eff and found it impossible to make _anything_ work.

Even if Prism isn't practical for practical programming, it's a big step forward, and worth a look just for the ideas.

stephendiehl.com/posts/prism/

stephendiehl.com

Prism: An Impure Functional Language With Typed Effects - Stephen Diehl

Personal blog of Stephen Diehl - Software engineer writing about technology, programming, and the future

@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@simonmic@fosstodon.org

I'm pleased to announce hledger 2.0 preview release 3!

Highlights:
- conventional file layout for rules/data/prices
- get command
- commodity aliases
- print aligns by decimal mark
- more intuitive precision behaviour
- more robust lot detection
- average cost basis methods
- customisable report titles
- prices --summary report
- a more robust roi report
- and many other improvements and fixes.

hledger.org/relnotes.html#2026
hledger.org/install

hledger.org

Install - hledger

plain text accounting, made easy

@lobsters@mastodon.social
@simonmic@fosstodon.org

I'm pleased to announce hledger 2.0 preview release 3!

Highlights:
- conventional file layout for rules/data/prices
- get command
- commodity aliases
- print aligns by decimal mark
- more intuitive precision behaviour
- more robust lot detection
- average cost basis methods
- customisable report titles
- prices --summary report
- a more robust roi report
- and many other improvements and fixes.

hledger.org/relnotes.html#2026
hledger.org/install

hledger.org

Install - hledger

plain text accounting, made easy

@abnv@fantastic.earth

So, you've heard of the new hotness that is , for creating reproducible and isolated development environments, and want to use it for your new project? But you are unclear about how to get started? Then this is the guide you are looking for: abhinavsarkar.net/posts/nix-fo

abhinavsarkar.net

Getting Started with Nix for Haskell

A guide to easily get started with Nix for Haskell projects.

@innocentzero@social.tchncs.de

"If you have used OCaml 5 this will feel familiar, except OCaml keeps its effects out of the types, so you find out about an unhandled one at runtime, in production, on a Friday."

"If you have used Haskell this will also feel familiar, except in Haskell you would be assembling a monad transformer stack, lifting each operation through every layer by hand, and explaining to a junior colleague that a monad is just a monoid in the category of endofunctors, what's the problem."

stephendiehl.com/posts/prism/

stephendiehl.com

Prism: An Impure Functional Language With Typed Effects - Stephen Diehl

Personal blog of Stephen Diehl - Software engineer writing about technology, programming, and the future

@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@haskman@functional.cafe

Announcing the June !

Our first talk is Type-level Programming in , presented by @abnv!

Like always, meet fellow FP heads, have great conversations, all skill levels welcome!

RSVP hasgeek.com/fpindia/bangalore-

hasgeek.com

Bangalore FP June 2026 meetup

Bangalore FP June 2026 meetup

@hackuador@functional.cafe

oi ya functional programming boffins and FP-curious minds. Brisbane Functional Programming Group Hack Day is on again, THIS SATURDAY at UQ. Be there or be a lambda cube! luma.com/0je3g6ft

Thanks to UQ and Professor Paul Vrbik for venue arrangement, Sirius-Beta Labs for lunch, and Thea and George for hosting this edition (yes, I am a lambda cube this time).

luma.com

BFPG Hack Day - June 2026 · Luma

Come to BFPG Hack Day for some wholesome fun hacking on side projects, tackling tutorials, grinding axes and shaving yaks! Work together or independently.…

@nina_kali_nina@tech.lgbt

My company is hiring an SRE with Haskell knowledge for my team, fully remote in the UK (some EU countries might be possible, but not guaranteed).

I'm mostly looking for someone who is confident in Haskell, or a strong SRE who would love to embrace Nix and Haskell. The company is making insurtech SaaS with a few cool twists. The company isn't anti-AI (I guess it's a sign of the times), but I am.

Don't hesitate to get in touch with me if you have any questions. If you're a queer person worried that you might not be qualified enough, definitely send me a line.

For extra clarity: I'm technically a hiring manager (gah!), but I am far from the only one calling the shots.

Job description: artificiallabsltd.teamtailor.c

artificiallabsltd.teamtailor.com

Site Reliability Engineer - Artificial Labs Ltd

About Artificial . Help shape the future of specialty insurance At Artificial, we’re building the next generation of technology for the specialty (re)insurance market. Our mission is to transform h...

@haskell@fosstodon.org

When a shiny new version of GHC comes out, it should be easy to upgrade. After all, the new compiler should be more capable than the previous version!

Simon Peyton-Jones explains in details what has been done, what is now possible, and what remains to be done in this quest of Making GHC upgrades easy.

blog.haskell.org/making-ghc-up

blog.haskell.org

Making GHC upgrades easy | The Haskell Programming Language's blog

@nina_kali_nina@tech.lgbt

My company is hiring an SRE with Haskell knowledge for my team, fully remote in the UK (some EU countries might be possible, but not guaranteed).

I'm mostly looking for someone who is confident in Haskell, or a strong SRE who would love to embrace Nix and Haskell. The company is making insurtech SaaS with a few cool twists. The company isn't anti-AI (I guess it's a sign of the times), but I am.

Don't hesitate to get in touch with me if you have any questions. If you're a queer person worried that you might not be qualified enough, definitely send me a line.

For extra clarity: I'm technically a hiring manager (gah!), but I am far from the only one calling the shots.

Job description: artificiallabsltd.teamtailor.c

artificiallabsltd.teamtailor.com

Site Reliability Engineer - Artificial Labs Ltd

About Artificial . Help shape the future of specialty insurance At Artificial, we’re building the next generation of technology for the specialty (re)insurance market. Our mission is to transform h...

@nina_kali_nina@tech.lgbt

My company is hiring an SRE with Haskell knowledge for my team, fully remote in the UK (some EU countries might be possible, but not guaranteed).

I'm mostly looking for someone who is confident in Haskell, or a strong SRE who would love to embrace Nix and Haskell. The company is making insurtech SaaS with a few cool twists. The company isn't anti-AI (I guess it's a sign of the times), but I am.

Don't hesitate to get in touch with me if you have any questions. If you're a queer person worried that you might not be qualified enough, definitely send me a line.

For extra clarity: I'm technically a hiring manager (gah!), but I am far from the only one calling the shots.

Job description: artificiallabsltd.teamtailor.c

artificiallabsltd.teamtailor.com

Site Reliability Engineer - Artificial Labs Ltd

About Artificial . Help shape the future of specialty insurance At Artificial, we’re building the next generation of technology for the specialty (re)insurance market. Our mission is to transform h...

@nina_kali_nina@tech.lgbt

My company is hiring an SRE with Haskell knowledge for my team, fully remote in the UK (some EU countries might be possible, but not guaranteed).

I'm mostly looking for someone who is confident in Haskell, or a strong SRE who would love to embrace Nix and Haskell. The company is making insurtech SaaS with a few cool twists. The company isn't anti-AI (I guess it's a sign of the times), but I am.

Don't hesitate to get in touch with me if you have any questions. If you're a queer person worried that you might not be qualified enough, definitely send me a line.

For extra clarity: I'm technically a hiring manager (gah!), but I am far from the only one calling the shots.

Job description: artificiallabsltd.teamtailor.c

artificiallabsltd.teamtailor.com

Site Reliability Engineer - Artificial Labs Ltd

About Artificial . Help shape the future of specialty insurance At Artificial, we’re building the next generation of technology for the specialty (re)insurance market. Our mission is to transform h...

@haskell@fosstodon.org

When a shiny new version of GHC comes out, it should be easy to upgrade. After all, the new compiler should be more capable than the previous version!

Simon Peyton-Jones explains in details what has been done, what is now possible, and what remains to be done in this quest of Making GHC upgrades easy.

blog.haskell.org/making-ghc-up

blog.haskell.org

Making GHC upgrades easy | The Haskell Programming Language's blog

@nina_kali_nina@tech.lgbt

My company is hiring an SRE with Haskell knowledge for my team, fully remote in the UK (some EU countries might be possible, but not guaranteed).

I'm mostly looking for someone who is confident in Haskell, or a strong SRE who would love to embrace Nix and Haskell. The company is making insurtech SaaS with a few cool twists. The company isn't anti-AI (I guess it's a sign of the times), but I am.

Don't hesitate to get in touch with me if you have any questions. If you're a queer person worried that you might not be qualified enough, definitely send me a line.

For extra clarity: I'm technically a hiring manager (gah!), but I am far from the only one calling the shots.

Job description: artificiallabsltd.teamtailor.c

artificiallabsltd.teamtailor.com

Site Reliability Engineer - Artificial Labs Ltd

About Artificial . Help shape the future of specialty insurance At Artificial, we’re building the next generation of technology for the specialty (re)insurance market. Our mission is to transform h...

@haskell@fosstodon.org

After becoming a regular contributor to haskell-language-server and even having his Google Summer of Code proposal accepted, Vidit wanted to talk about his experience on approaching Haskell code bases.

“Contributing to Haskell Through a Beginner’s Lens” by Vidit Odedra

blog.haskell.org/contributing-

blog.haskell.org

Contributing to Haskell Through a Beginner’s Lens | The Haskell Programming Language's blog

@qwreey@nyanpuppu.moe
많은 양의 haskell 연산자가 무더기로 쌓여있는 '전부 똑같은 거 아닌가요?' 탬플릿
ALT text

많은 양의 haskell 연산자가 무더기로 쌓여있는 '전부 똑같은 거 아닌가요?' 탬플릿

@v2editor@mastodon.social · Reply to v2 Editor
@v2editor@mastodon.social · Reply to v2 Editor
@abnv@fantastic.earth

I hear rumors that people are making their agents write scripts instead of so that they can be executed without sandbox or approval. It will be funny if Lean or (a fully dependent typed) become the most popular programming language in few years. So much for avoiding success.

@abnv@fantastic.earth

I hear rumors that people are making their agents write scripts instead of so that they can be executed without sandbox or approval. It will be funny if Lean or (a fully dependent typed) become the most popular programming language in few years. So much for avoiding success.

@abnv@fantastic.earth

Ever since I figured out how to build static executables for code, I've being deploying all my Haskell projects as static binaries. I can't believe how much disk space it saves in some cases. The SSG that builds my website used to take more than 5GB; now it takes about 80MB!

Screenshot of a terminal with text:

> nix path-info -Sh (nix-build --quiet nix/release.nix)
/nix/store/84vc1j299cf1578kspj7075kfhhl4ffa-site-1.0.0    5.4G
> nix path-info -Sh (nix-build --quiet --arg static true nix/release.nix)
/nix/store/ciag7rx<mdvaa19919jg6bybbwxp1s9n-site-1.0.0    84.0М
ALT text

Screenshot of a terminal with text: > nix path-info -Sh (nix-build --quiet nix/release.nix) /nix/store/84vc1j299cf1578kspj7075kfhhl4ffa-site-1.0.0 5.4G > nix path-info -Sh (nix-build --quiet --arg static true nix/release.nix) /nix/store/ciag7rx<mdvaa19919jg6bybbwxp1s9n-site-1.0.0 84.0М

@abnv@fantastic.earth

feed-repeat now has a (simple) website: abhin4v.github.io/feed-repeat/

abhin4v.github.io

feed-repeat

@abnv@fantastic.earth

feed-repeat now has a (simple) website: abhin4v.github.io/feed-repeat/

abhin4v.github.io

feed-repeat

@Jose_A_Alonso@mathstodon.xyz
@pmidden@fosstodon.org

In , I have "load :: Bool -> Bool -> Struct" where "data Struct = Struct (Maybe X) (Maybe Y)" (where the booleans specify whether X and Y are loaded and are "Just"). If the two booleans are more or less known at compile-time, can I improve on this, ditching the Maybe?

@puffnfresh@mastodon.social

I've been working on continually exporting 's stack traces to pprof format, making GHC compatible with existing tools, e.g. Pyroscope, Speedscope, etc.

Simple tests give it about a 2% overhead on a silly Scotty/HTTP example app.

That brings it in line with other languages. For Atlassian Marketplace, I used AWS CodeGuru Profiler for the Scala code, and it was invaluable. For Obsidian Systems we've been using Grafana Pyroscope on some Go code.

Haskell call graphs in Grafana Pyroscope.
ALT text

Haskell call graphs in Grafana Pyroscope.

Haskell call stack visualised with "go tool pprof"
ALT text

Haskell call stack visualised with "go tool pprof"

@haskell@fosstodon.org

The past years have seen horrendous attacks towards trans people. We have a duty to protect the most vulnerable members of our communities.

There is no without the trans people who have shaped it through the years.

This June is a month of celebrations, but the struggle continues. ✊🏳️‍⚧️λ

The trans flag with a greek lowecase lambda letter in black on it.
ALT text

The trans flag with a greek lowecase lambda letter in black on it.

@haskell@fosstodon.org

The past years have seen horrendous attacks towards trans people. We have a duty to protect the most vulnerable members of our communities.

There is no without the trans people who have shaped it through the years.

This June is a month of celebrations, but the struggle continues. ✊🏳️‍⚧️λ

The trans flag with a greek lowecase lambda letter in black on it.
ALT text

The trans flag with a greek lowecase lambda letter in black on it.

@haskell@fosstodon.org

The past years have seen horrendous attacks towards trans people. We have a duty to protect the most vulnerable members of our communities.

There is no without the trans people who have shaped it through the years.

This June is a month of celebrations, but the struggle continues. ✊🏳️‍⚧️λ

The trans flag with a greek lowecase lambda letter in black on it.
ALT text

The trans flag with a greek lowecase lambda letter in black on it.

@haskell@fosstodon.org

The past years have seen horrendous attacks towards trans people. We have a duty to protect the most vulnerable members of our communities.

There is no without the trans people who have shaped it through the years.

This June is a month of celebrations, but the struggle continues. ✊🏳️‍⚧️λ

The trans flag with a greek lowecase lambda letter in black on it.
ALT text

The trans flag with a greek lowecase lambda letter in black on it.

@pmidden@fosstodon.org

Finally got a good use-case for property-based tests (PBT) in . Had a function that really enforced an invariant. Given a number, using test to be tested function will output a string that's less than 'n' chars long. And wow did PBT help!

@haskell@fosstodon.org
@lobsters@mastodon.social
@haskell@fosstodon.org
@haskell@fosstodon.org
@abnv@fantastic.earth

Over the weekend, I spent a couple of hours through Patrick Thomson's series of blog posts on Recursion Schemes with blog.sumtypeofway.com/posts/re, and it has been most helpful in understanding the topic. I have tried reading the docs of the eponymous package before, to no avail. That's why I love reading (and writing) tutorials.

I downloaded the posts and converted them to an e-book for offline reading. It was over a hundred pages but it was so engrossing, I couldn't put it down! There are not many blog posts that I could say the same about. Definitely a recommended read if you are interested in and .

blog.sumtypeofway.com

adventures in uncertainty: Recursion Schemes, Part VI: Comonads, Composition, and Generality

@haskell@fosstodon.org
@fornever@dotnet.social

Took me a couple of months in total, but finally I've released Haskeletor v2.0.0 — an plugin for projects!

This time, in v2.0.0, it is really an IntelliJ plugin — no longer bound to IDEA, compatible with all the IDEs from the family!

There are a lot of plans how to move farther (e.g. rely on HLS instead of the current tool set), but for now I've released it and plan to switch to other tasks — the ones that made me to implement Haskell tooling in the first place.

@fornever@dotnet.social

Took me a couple of months in total, but finally I've released Haskeletor v2.0.0 — an plugin for projects!

This time, in v2.0.0, it is really an IntelliJ plugin — no longer bound to IDEA, compatible with all the IDEs from the family!

There are a lot of plans how to move farther (e.g. rely on HLS instead of the current tool set), but for now I've released it and plan to switch to other tasks — the ones that made me to implement Haskell tooling in the first place.

@haskell@fosstodon.org
@lobsters@mastodon.social
@adolfoneto@bertha.social
@haskell@fosstodon.org
@haskell@fosstodon.org
@haskell@fosstodon.org
@abnv@fantastic.earth

In an alternative timeline where is the norm instead of Object-oriented programming, and is the most popular instead of , there is a list of tutorials trying to explain what Objects are to programmers in terms of FP concepts, the most popular of which is, “Objects are Comonads”.

However, we don't live in that timeline, so we'll have to be content with the inverse article, “Comonads are Objects” haskellforall.com/2013/02/you- .

haskellforall.com

Comonads are objects

Haskell programmers popularized the use of monads to structure imperative computations, complete with syntactic sugar in the form of do not...

@abnv@fantastic.earth

Wrote some in as an using the Clay library. Gotta say, writing type-safe CSS is a really nice experience.

```haskell
pageStyle = do
body ? do
header ? do
textAlign center
main_ ** article ? do
small ? do
fontSize $ em 0.5
marginLeft $ em 0.3
".meta" ? do
display flex
justifyContent spaceBetween
ul # ".tags" ? do
paddingLeft $ em 0
li ? do
display inlineBlock
backgroundColor $ rgb 230 230 250
color $ rgb 34 34 34
margin (em 0.2) (em 0.1) (em 0.2) (em 0.1)
padding (em 0.1) (em 0.5) (em 0.1) (em 0.5)
whiteSpace nowrap
fontSizeCustom smaller
query CM.screen [CM.prefersColorScheme CM.dark] $ do
backgroundColor $ rgb 72 57 165
color $ rgb 217 216 220
footer ? do
textAlign center
fontSizeCustom smaller
borderTop 1 dashed black
```

@patrikja@functional.cafe

In January 2027, I will teach the first instalment of the new BSc course "Functional Programming: continuation course" (joint between Chalmers and UGOT). share.google/int8wna1Pjo9T1tGE
Within a month or so, I need to decide on the course literature. I'd be very happy to receive thoughts, suggestions, warnings, etc. about what you think would work, or not.
More details below:

Learning outcomes:
Knowledge and understanding:

+ Explain and apply fundamental abstractions in functional programming, including lazy/strict evaluation, functors, & monads, and describe how these abstractions can be used to handle state, exceptions, and I/O in a purely functional way.
+ Explain how algebraic properties such as associativity and commutativity enable divide-and-conquer and parallel evaluation in pure functional programs, and discuss how purity and referential transparency support the design of compositional embedded domain-specific languages (EDSLs).

Skills and abilities:

+ Design, structure, and implement functional programs and small EDSLs using appropriate type classes, algebraic operators, and data structures for efficient and, where appropriate, parallel computation.
+ Apply functional techniques such as recursion schemes, memoization, and algebraic composition to implement and reason about non-trivial algorithms.
+ Use relevant tools and libraries to develop, test, and document maintainable programs, including performance analysis and identification of common inefficiencies.
+ Structure and solve real-world programming problems in a functional style, integrating abstraction, testing, and reasoning for correctness and efficiency.

Judgement and approach:

+ Critically assess the suitability of abstractions and algebraic structures for specific programming problems, through reflection on the trade-offs between abstraction, performance, and resource use.
+ Evaluate program design decisions and correctness using property-based testing, algebraic properties, and equational reasoning.
+ Demonstrate responsibility in program design and collaboration, ensuring modularity, clear documentation, and maintainability.

chalmers.se

Functional Programming: continuation course

@haskell@fosstodon.org
@patrikja@functional.cafe

In January 2027, I will teach the first instalment of the new BSc course "Functional Programming: continuation course" (joint between Chalmers and UGOT). share.google/int8wna1Pjo9T1tGE
Within a month or so, I need to decide on the course literature. I'd be very happy to receive thoughts, suggestions, warnings, etc. about what you think would work, or not.
More details below:

Learning outcomes:
Knowledge and understanding:

+ Explain and apply fundamental abstractions in functional programming, including lazy/strict evaluation, functors, & monads, and describe how these abstractions can be used to handle state, exceptions, and I/O in a purely functional way.
+ Explain how algebraic properties such as associativity and commutativity enable divide-and-conquer and parallel evaluation in pure functional programs, and discuss how purity and referential transparency support the design of compositional embedded domain-specific languages (EDSLs).

Skills and abilities:

+ Design, structure, and implement functional programs and small EDSLs using appropriate type classes, algebraic operators, and data structures for efficient and, where appropriate, parallel computation.
+ Apply functional techniques such as recursion schemes, memoization, and algebraic composition to implement and reason about non-trivial algorithms.
+ Use relevant tools and libraries to develop, test, and document maintainable programs, including performance analysis and identification of common inefficiencies.
+ Structure and solve real-world programming problems in a functional style, integrating abstraction, testing, and reasoning for correctness and efficiency.

Judgement and approach:

+ Critically assess the suitability of abstractions and algebraic structures for specific programming problems, through reflection on the trade-offs between abstraction, performance, and resource use.
+ Evaluate program design decisions and correctness using property-based testing, algebraic properties, and equational reasoning.
+ Demonstrate responsibility in program design and collaboration, ensuring modularity, clear documentation, and maintainability.

chalmers.se

Functional Programming: continuation course

@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@byorgey@mathstodon.xyz

I wanted a function to efficiently compute the conjugate of an integer partition. I think I know how to write it, but it's fiddly. There's a nice, succinct functional specification:

conjugate = reverse . map length . transpose . map (`replicate` ())

but it's slow. Now I'm wondering whether it's possible to derive an efficient version from this specification, -Meertens style. Anyone know of previous work along these lines? Or should I add it to my list of interesting projects?

@haskell@fosstodon.org
@haskell@fosstodon.org
@haskell@fosstodon.org
@haskell@fosstodon.org
@hackuador@functional.cafe

Brisbane Functional Programming Group May 12: Tim Lamberton will teach us about data type derivatives and zippers, and Carlo will introduce Datastar, his new framework for interactive web apps. Be there or a be a lambda cube! luma.com/72tqx0nh

luma.com

BFPG Meetup - May 2026 - zippers + the Datastar framework · Luma

Join the BFPG Discord: https://discord.gg/yYz2d8w7FY Agenda 18:00: Welcome and setup Presentation #1: What is the derivative of a data type? - Tim…

@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@haskell@fosstodon.org
@joeyh@sunbeam.city

Wow, it's been too long since I read a really good blog post.

blog.haskell.org/a-couple-mill

Putting this away to enjoy later, I was up at 6 am working out how to winch a huge hot water heater from a pickup truck onto my porch. Which we succeeded at eventually..

blog.haskell.org

A Couple Million Lines of Haskell: Production Engineering at Mercury | The Haskell Programming Language's blog

What it takes to run 2 million lines of Haskell in production at a fintech company serving 300,000 businesses.

@joeyh@sunbeam.city

Wow, it's been too long since I read a really good blog post.

blog.haskell.org/a-couple-mill

Putting this away to enjoy later, I was up at 6 am working out how to winch a huge hot water heater from a pickup truck onto my porch. Which we succeeded at eventually..

blog.haskell.org

A Couple Million Lines of Haskell: Production Engineering at Mercury | The Haskell Programming Language's blog

What it takes to run 2 million lines of Haskell in production at a fintech company serving 300,000 businesses.

@joeyh@sunbeam.city

Wow, it's been too long since I read a really good blog post.

blog.haskell.org/a-couple-mill

Putting this away to enjoy later, I was up at 6 am working out how to winch a huge hot water heater from a pickup truck onto my porch. Which we succeeded at eventually..

blog.haskell.org

A Couple Million Lines of Haskell: Production Engineering at Mercury | The Haskell Programming Language's blog

What it takes to run 2 million lines of Haskell in production at a fintech company serving 300,000 businesses.

@Jose_A_Alonso@mathstodon.xyz

A monadic implementation of functional logic programs. ~ Michael Hanus, Kai-Oliver Prott, Finn Teegen. arxiv.org/abs/2604.27863v1

arxiv.org

A Monadic Implementation of Functional Logic Programs

Functional logic languages are a high-level approach to programming by combining the most important declarative features. They abstract from small-step operational details so that programmers can concentrate on the logical aspects of an application. This is supported by appropriate evaluation strategies. Demand-driven evaluation from functional programming is amalgamated with non-determinism from logic programming so that solutions or values are computed whenever they exist. This frees the programmer from considering the influence of an operational strategy on the success of a computation, but it is a challenge to the language implementer. A non-deterministic demand-driven strategy might duplicate unevaluated choices of an expression, which could duplicate the computational effort. In recent implementations, this problem has been tackled by adding a kind of memoization of non-deterministic choices to the expression under evaluation. Since this has been implemented in imperative target languages, it was unclear whether this could also be supported in a functional programming environment like Haskell. This paper presents a solution to this challenge by transforming functional logic programs into a monadic representation. Although this transformation is not new, we present an implementation of the monadic interface which supports memoization in non-deterministic branches. Additionally, we include more advanced features of functional logic languages, namely functional patterns and encapsulated search, in our approach. By optimizing our implementation for purely functional computations with both a static and dynamic approach, we are able to achieve a promising performance that outperforms current compilers for Curry.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@abnv@fantastic.earth

Would people be interested in a series of posts where I implement the C from "Writing a C Compiler" book by Nora Sandler in ? I'd focus on Haskell specific libraries and techniques with some additional bits not present in the book.

  • Yes21 (84%)
  • No3 (12%)
  • I hate book implementations1 (4%)
@lobsters@mastodon.social
@DiazCarrete@hachyderm.io
@DiazCarrete@hachyderm.io
@Jose_A_Alonso@mathstodon.xyz
@lobsters@mastodon.social
@haskell@fosstodon.org
@kosmikus@functional.cafe
@lobsters@mastodon.social
@mathr@post.lurk.org

remembering that time I tried to implement arbitrary precision arithmetic in with precision in the type, only some operations actually used higher precision before rounding. the resulting unbounded recursion led to a heap profile graph that was an ever growing wedge of Num dictionary until heap exhaustion (and nothing worked).

@abnv@fantastic.earth

JSON is probably the most used standard file format for storing and transmitting data on the Internet in recent times. It has a simple syntax with only four scalar data types and two composite data types. So, writing a parser for is a great exercise for learning the basics of parsing.

That's exactly what I did: I wrote a JSON from scratch in . Read my post to learn about basics of parsing, nuances of the JSON syntax, and parser combinators and property-based in Haskell: abhinavsarkar.net/posts/json-p

A transition diagram depicting the JSON syntax.
ALT text

A transition diagram depicting the JSON syntax.

@Jose_A_Alonso@mathstodon.xyz
@lobsters@mastodon.social
@haskell@fosstodon.org
@haskell@fosstodon.org
@haskell@fosstodon.org

Any appetite in the crowd for "A CTO's Guide to Adopting "? If so, there would be things like:

* Observability
* Domain Design
* Just Enough Haskell To Be Dangerous™
* Library recommendations for your HTTP/gRPC/DB needs
* SBOM

What else would you like to see?

@meejah@mastodon.social · Reply to David Reed

@aoristdual yeah .. on the flip side, the documentation is really good in general and the compiler gives very good hints and error messages (in general).

I don't think I would have succeeded at any (or ) learning without IDE support -- these languages are what made me make LSP work correctly, finally :)

@Jose_A_Alonso@mathstodon.xyz
@mathr@post.lurk.org

remembering that time I tried to implement arbitrary precision arithmetic in with precision in the type, only some operations actually used higher precision before rounding. the resulting unbounded recursion led to a heap profile graph that was an ever growing wedge of Num dictionary until heap exhaustion (and nothing worked).

@abnv@fantastic.earth

Comparing the chart of tutorials by year[1] with the Gartner hype cycle graph, it seems like we are almost at the Peak of Inflated Expectations phase now.

[1]: From the list of Monad tutorials (wiki.haskell.org/Monad_tutoria).

In my lifetime, I hope to see the Slope of Enlightenment phase when people stop asking what a Monad is, and the further Plateau of Productivity phase when everyone knows what it is.

A line chart showing number of Monad tutorials published yearly from 1990 to 2023. The number grows slowly at the beginning, then rises sharply starting 2015, then seems to plateau around 2022.
ALT text

A line chart showing number of Monad tutorials published yearly from 1990 to 2023. The number grows slowly at the beginning, then rises sharply starting 2015, then seems to plateau around 2022.

The graph of the Gartner Hype Cycle.
ALT text

The graph of the Gartner Hype Cycle.

@abnv@fantastic.earth · Reply to Abhinav 🧭

I finished Make A in C++20 in about 2600 lines of code. I learned a lot about modern and managed to write the whole without writing a single C-style macro or pointer arithmetic or type casting.

Compared to my usual choice , C++ is way more verbose. I feel I can write the same interpreter in (idiomatic) Haskell in less than 800 LOCs. But it’ll probably be much slower.

Some time later in the year, I want to attempt writing a compiler for MAL in Haskell via QBE.

@abnv@fantastic.earth
@michabbb@vivaldi.net · Reply to michabbb

🚀 Performance on a completely different level:

Written in with the Warp HTTP server. JSON gets serialized directly in SQL. Connection pooling via Hasql. Subsecond response times at 2000 req/sec — even on free tier hosting.

🔐 Security is built in, not bolted on:
Auth runs via JWT. Authorization is controlled directly in the database through roles. One single declarative source of truth for security. The server assumes the identity of the authenticated user.

@jaror@social.edu.nl
@jaror@social.edu.nl
@abnv@fantastic.earth
@DiazCarrete@hachyderm.io
@haskell@fosstodon.org
@sushee@ohai.social
@hackuador@functional.cafe

Brisbane Functional Programming Group April meetup, Tue 14th. Jack will present about using with Lambda. And we will have a Hack Day review where people will demo or share what they did at Hack Day. Be there or be a lambda cube!

luma.com/cjlche2l

luma.com

BFPG Meetup - April 2026 - Haskell on AWS Lambda + Hack Day retro · Luma

Join the BFPG Discord: https://discord.gg/yYz2d8w7FY Agenda 18:00: Welcome and setup Presentation #1: Lambda on Lambda: Running Haskell on AWS's…

@hackuador@functional.cafe

Brisbane Functional Programming Group April meetup, Tue 14th. Jack will present about using with Lambda. And we will have a Hack Day review where people will demo or share what they did at Hack Day. Be there or be a lambda cube!

luma.com/cjlche2l

luma.com

BFPG Meetup - April 2026 - Haskell on AWS Lambda + Hack Day retro · Luma

Join the BFPG Discord: https://discord.gg/yYz2d8w7FY Agenda 18:00: Welcome and setup Presentation #1: Lambda on Lambda: Running Haskell on AWS's…

@sushee@ohai.social
@haskell@fosstodon.org

The editors of the Blog are happy to announce a new series of articles called "Haskellers from the trenches", where we invite experienced engineers to talk about their subjects of expertise, best practices, and production tales.

Our first guest is @iankduncan.com with "A Couple Million Lines of Haskell: Production Engineering at Mercury"

blog.haskell.org/a-couple-mill

blog.haskell.org

A Couple Million Lines of Haskell: Production Engineering at Mercury | The Haskell Programming Language's blog

What it takes to run 2 million lines of Haskell in production at a fintech company serving 300,000 businesses.

@abnv@fantastic.earth

I'm writing a series of blog posts, in which I write a and a for arithmetic in . We explore the following topics in the series:

- Parsing arithmetic expressions to ASTs.
- Compiling ASTs to bytecode.
- Interpreting ASTs.
- Efficiently executing bytecode in a VM.
- Disassembling bytecode and decompiling opcodes for debugging and testing.
- Unit testing and property-based testing for our compiler and VM.
- Benchmarking our code to see how the different passes perform.
- All the while keeping an eye on performance.

The second post of the series that focuses on writing the is now out: abhinavsarkar.net/posts/arithm

abhinavsarkar.net

A Fast Bytecode VM for Arithmetic: The Compiler

We write a fast bytecode VM for arithmetic in Haskell.

@DiazCarrete@hachyderm.io

"Compiler and runtime support for continuation marks" (PLDI 2020) dl.acm.org/doi/10.1145/3385412
"Continuation marks enable dynamic binding and context inspection in a language with proper handling of tail calls and first-class, multi-prompt, delimited continuations."

GHC proposal: "scoped thread-locals" github.com/ghc-proposals/ghc-p
"efficient storage and lookup for immutable context
attached to the current Haskell thread, which is inherited by child threads."

github.com

scoped thread-locals proposal by edmundnoble · Pull Request #751 · ghc-proposals/ghc-proposals

This is a proposal for introducing scoped thread-locals into GHC Haskell. Scoped thread-locals provide efficient storage and lookup for immutable context attached to the current Haskell thread, whi...

@hackuador@functional.cafe
@hackuador@functional.cafe
@hackuador@functional.cafe
@shanecelis@mastodon.gamedev.place

“I have no IO monad and I must scream.”

“Sorry. Emitting heat is the best I can do.”

CUSTOMER: I have no IO monad and I must scream.

PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.
ALT text

CUSTOMER: I have no IO monad and I must scream. PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.

@Jose_A_Alonso@mathstodon.xyz
@shanecelis@mastodon.gamedev.place

“I have no IO monad and I must scream.”

“Sorry. Emitting heat is the best I can do.”

CUSTOMER: I have no IO monad and I must scream.

PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.
ALT text

CUSTOMER: I have no IO monad and I must scream. PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.

@shanecelis@mastodon.gamedev.place

“I have no IO monad and I must scream.”

“Sorry. Emitting heat is the best I can do.”

CUSTOMER: I have no IO monad and I must scream.

PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.
ALT text

CUSTOMER: I have no IO monad and I must scream. PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.

@abnv@fantastic.earth
@shanecelis@mastodon.gamedev.place

“I have no IO monad and I must scream.”

“Sorry. Emitting heat is the best I can do.”

CUSTOMER: I have no IO monad and I must scream.

PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.
ALT text

CUSTOMER: I have no IO monad and I must scream. PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.

@shanecelis@mastodon.gamedev.place

“I have no IO monad and I must scream.”

“Sorry. Emitting heat is the best I can do.”

CUSTOMER: I have no IO monad and I must scream.

PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.
ALT text

CUSTOMER: I have no IO monad and I must scream. PAWN SHOP GUYS: Sorry. Emitting heat is the best I can do.

@Jose_A_Alonso@mathstodon.xyz
@robinp@mastodon.social

Guys, I realized I was doing development stone-age style.

You _need_ to try this, these new tools are absolute game-changers, unlocking 2x to 10x productivity.

I know this is not a popular opinion, but look, we need to keep pace with the changes of times. It might feel hard at first, or at least feel alien, but, we need to part from our old, sluggish, slow ways.

So, enable the DuplicateRecordFields and OverloadedRecordDot extensions, now!

@jaror@social.edu.nl

Packages like `text` reach into the unstable bowels of to avoid allocating intermediate structures when reading IO.

But it is possible to do fusible lazy IO:

```
produce :: IO [Char]
produce = IO $ \s0 ->
(# s0 , build $ \c n ->
let go s = case runIO getChar s of
(# s' , x #) -> c x (go s')
in go s0
#)
```

Perhaps GHC could expose something like that and the text package could use it.

@jaror@social.edu.nl

Packages like `text` reach into the unstable bowels of to avoid allocating intermediate structures when reading IO.

But it is possible to do fusible lazy IO:

```
produce :: IO [Char]
produce = IO $ \s0 ->
(# s0 , build $ \c n ->
let go s = case runIO getChar s of
(# s' , x #) -> c x (go s')
in go s0
#)
```

Perhaps GHC could expose something like that and the text package could use it.

@poseidon@ecoevo.social
@haskell@fosstodon.org
@haskell@fosstodon.org
@6d03@mathstodon.xyz

Wot?

```
• Couldn't match expected type ‘bytestring-0.11.5.3:Data.ByteString.Internal.Type.ByteString’
with actual type ‘bytestring-0.11.5.3:Data.ByteString.Lazy.Internal.ByteString’
```

@abnv@fantastic.earth

I ported @mattmight’s conversion code (matt.might.net/articles/cps-co) to and after some fighting with the type system, it worked! To make the work with the Cont monad, I had to remove recursive lets and hence, functions being able to call themselves recursively, but the rest works fine.

The attached images show the conversion of the Fibonacci function into the CPS version.

Fibonacci function in Lisp:

(let
  ([fib
     (λ (n)
       (let
         ([fib'
            (λ (n f)
              (if (= n 0)
                0
                (if (= n 1)
                  1 
                  (+ (f (- n 1) f) (f (- n 2) f)))))])
         (fib' n fib')))])
  (fib 10))
ALT text

Fibonacci function in Lisp: (let ([fib (λ (n) (let ([fib' (λ (n f) (if (= n 0) 0 (if (= n 1) 1 (+ (f (- n 1) f) (f (- n 2) f)))))]) (fib' n fib')))]) (fib 10))

Fibonacci function in Lisp:

(let
  ([fib
     (λ (n)
       (let
         ([fib'
            (λ (n f)
              (if (= n 0)
                0
                (if (= n 1)
                  1 
                  (+ (f (- n 1) f) (f (- n 2) f)))))])
         (fib' n fib')))])
  (fib 10))
ALT text

Fibonacci function in Lisp: (let ([fib (λ (n) (let ([fib' (λ (n f) (if (= n 0) 0 (if (= n 1) 1 (+ (f (- n 1) f) (f (- n 2) f)))))]) (fib' n fib')))]) (fib 10))

CPS version of Fibonacci function in Lisp:

(let
  ([fib
     (λ (n k0)
       (let
         ([fib'
            (λ (n f k1)
              ((λ (k2)
                 ((λ (v3)
                    (if v3
                      (k2 0)
                      ((λ (k4)
                         ((λ (v5)
                            (if v5
                              (k4 1)
                              ((λ (v9)
                                 (f v9 f
                                   (λ (v6)
                                     ((λ (v8)
                                        (f v8 f 
                                          (λ (v7) 
                                            (k4 (+ v6 v7)))))
                                      (- n 2)))))
                               (- n 1))))
                          (= n 1)))
                       k2)))
                  (= n 0)))
               k1))])
         (fib' n fib' k0)))])
  (fib 10 return))
ALT text

CPS version of Fibonacci function in Lisp: (let ([fib (λ (n k0) (let ([fib' (λ (n f k1) ((λ (k2) ((λ (v3) (if v3 (k2 0) ((λ (k4) ((λ (v5) (if v5 (k4 1) ((λ (v9) (f v9 f (λ (v6) ((λ (v8) (f v8 f (λ (v7) (k4 (+ v6 v7))))) (- n 2))))) (- n 1)))) (= n 1))) k2))) (= n 0))) k1))]) (fib' n fib' k0)))]) (fib 10 return))

CPS version of Fibonacci function in Lisp:

(let
  ([fib
     (λ (n k0)
       (let
         ([fib'
            (λ (n f k1)
              ((λ (k2)
                 ((λ (v3)
                    (if v3
                      (k2 0)
                      ((λ (k4)
                         ((λ (v5)
                            (if v5
                              (k4 1)
                              ((λ (v9)
                                 (f v9 f
                                   (λ (v6)
                                     ((λ (v8)
                                        (f v8 f 
                                          (λ (v7) 
                                            (k4 (+ v6 v7)))))
                                      (- n 2)))))
                               (- n 1))))
                          (= n 1)))
                       k2)))
                  (= n 0)))
               k1))])
         (fib' n fib' k0)))])
  (fib 10 return))
ALT text

CPS version of Fibonacci function in Lisp: (let ([fib (λ (n k0) (let ([fib' (λ (n f k1) ((λ (k2) ((λ (v3) (if v3 (k2 0) ((λ (k4) ((λ (v5) (if v5 (k4 1) ((λ (v9) (f v9 f (λ (v6) ((λ (v8) (f v8 f (λ (v7) (k4 (+ v6 v7))))) (- n 2))))) (- n 1)))) (= n 1))) k2))) (= n 0))) k1))]) (fib' n fib' k0)))]) (fib 10 return))

@hackuador@functional.cafe
@abnv@fantastic.earth

I'm starting a series of blog posts, in which I write a and a for arithmetic in . We explore the following topics in the series:

- Parsing arithmetic expressions to ASTs.
- Compiling ASTs to bytecode.
- Interpreting ASTs.
- Efficiently executing bytecode in a VM.
- Disassembling bytecode and decompiling opcodes for debugging and testing.
- Unit testing and property-based testing for our compiler and VM.
- Benchmarking our code to see how the different passes perform.
- All the while keeping an eye on performance.

The first post of the series that focuses on writing the is now out: abhinavsarkar.net/posts/arithm

abhinavsarkar.net

A Fast Bytecode VM for Arithmetic: The Parser

We write a fast bytecode VM for arithmetic in Haskell.

@abnv@fantastic.earth

I've created a PR in , a simple setup framework, to add support for easy building of statically-linked executables (github.com/pwm/nixkell/pull/50). I'd appreciate it if any Nixkell users gives it a try for their projects. I've been using this code for a couple of my projects, and it works fine for me, but I'd like to have more working examples.

github.com

Add support for building statically-linked executable by abhin4v · Pull Request #50 · pwm/nixkell

This PR adds support for easily building statically-linked executable using Nixkell and Nix. Majorly, it: adds an overlays-static.nix file that configures GHC and Haskell packages for building sta...

@abnv@fantastic.earth

After seven years of meticulously formatting and aligning all the source code of my static site generator by hand, I finally moved to an auto-formatter today (Ormolu).

Screenshot of the summary of a git commit that says:

Reformats Haskell code
66 changed files with 3201 additions and 2845 deletions
ALT text

Screenshot of the summary of a git commit that says: Reformats Haskell code 66 changed files with 3201 additions and 2845 deletions

@haskell@fosstodon.org
@abnv@fantastic.earth

Every year I try to solve some problems from the competition in a not straightforward way. This year I solved the day 19 problem “Aplenty” by compiling the problem input to an executable file.

A new post: abhinavsarkar.net/posts/compil

abhinavsarkar.net

Solving Advent of Code

We solve Advent of Code '23 'Aplenty' by compiling the problem input.

@robinp@mastodon.social

Guys, I realized I was doing development stone-age style.

You _need_ to try this, these new tools are absolute game-changers, unlocking 2x to 10x productivity.

I know this is not a popular opinion, but look, we need to keep pace with the changes of times. It might feel hard at first, or at least feel alien, but, we need to part from our old, sluggish, slow ways.

So, enable the DuplicateRecordFields and OverloadedRecordDot extensions, now!

@abnv@fantastic.earth

Upgraded my website generator to use 9.4 and it took two hours to build. Well, that's the cost I pay for using bleeding edge software.

@robinp@mastodon.social

Guys, I realized I was doing development stone-age style.

You _need_ to try this, these new tools are absolute game-changers, unlocking 2x to 10x productivity.

I know this is not a popular opinion, but look, we need to keep pace with the changes of times. It might feel hard at first, or at least feel alien, but, we need to part from our old, sluggish, slow ways.

So, enable the DuplicateRecordFields and OverloadedRecordDot extensions, now!

@Jose_A_Alonso@mathstodon.xyz
@abnv@fantastic.earth

Writing an for is almost a rite of passage for any programming language implementer, and it’s my turn now. In this post, I write not one but four Brainfuck in : abhinavsarkar.net/posts/brainf

Please boost for reach. If you have any questions or comments, please reply to this post.

abhinavsarkar.net

Interpreting Brainfuck in Haskell

We write a few Brainfuck interpreters in Haskell.

@Jose_A_Alonso@mathstodon.xyz
@abnv@fantastic.earth

After a gap of 1.5 years since the last part, I have finally finished writing the third part of my post series on implementing Co. Planning to publish it this weekend.

Implementing Co, a Small Interpreted Language With Coroutines #3: Adding Coroutines
ALT text

Implementing Co, a Small Interpreted Language With Coroutines #3: Adding Coroutines

@ramin_hal9001@fe.disroot.org · Reply to Hippo 🍉

@badrihippo modern frameworks like React, Vue, and Van.js are all very similar, but I have not seen a consistent name for this family of frameworks. I have heard it called “The Elm Architecture,” because they are loosely based on how the Elm programming language originally did GUI programming in the browser. I have also heard it called the Model-View-Update paradigm. But most people just call it “React-like” or “Reactive Programming” because they are all similar to the very popular “React.js” framework.

Note that this should not be confused with Functional Reactive Programming (FRP), although the two are not completely different. As I understand it, React-like GUIs and FRP can both be implemented on top of a more powerful and more general computation model called “propagators” (here is the PDF of the original Propagators paper).

@dthompson wrote a really good blog post about FRP, propagators, and React-like frameworks.

I hope that helps, but I am not as well-versed in the theory of this stuff as I should be.

Oh, and I should say, before React-like took over the world wide web, GUI programming was mostly intertwined with Object Oriented Programming and design, so a good place to start might be to read up on Smalltalk OOP and GUI design.

#tech #software #GUI #ReactiveProgramming #FRP #Scheme #Haskell #SchemeLang #Propagators #ElmArchitecture #ReactJS #Smalltalk #OOP #ObjectOriented

fe.disroot.org

FEDIsroot

@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@kosmikus@functional.cafe
@haskell@fosstodon.org
@m4lvin@goto.fiets.pizza

I always enjoy giving this lecture 😃 #haskell

Blackboard with a diagram about "Functor" in Haskell. The example functions used are "length :: String -> Int" and "odd :: Int -> Bool". The diagram also shows the two functor laws as "fmap id = id" and "fmap odd . fmap length = fmap (odd.length)".
ALT text

Blackboard with a diagram about "Functor" in Haskell. The example functions used are "length :: String -> Int" and "odd :: Int -> Bool". The diagram also shows the two functor laws as "fmap id = id" and "fmap odd . fmap length = fmap (odd.length)".

@abnv@fantastic.earth

It is a good day to unleash the agent of chaos.

Screenshot of the documentation of the Haskell function accursedUnutterablePerformIO:

accursedUnutterablePerformIO :: IO a -> a

This "function" has a superficial similarity to unsafePerformIO but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet.

Witness the trail of destruction:

    https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7
    https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da
    https://github.com/haskell/aeson/commit/720b857e2e0acf2edc4f5512f2b217a89449a89d
    https://ghc.haskell.org/trac/ghc/ticket/3486
    https://ghc.haskell.org/trac/ghc/ticket/3487
    https://ghc.haskell.org/trac/ghc/ticket/7270
    https://gitlab.haskell.org/ghc/ghc/-/issues/22204

Do not talk about "safe"! You do not know what is safe!

Yield not to its blasphemous call! Flee traveller! Flee or you will be corrupted and devoured!
ALT text

Screenshot of the documentation of the Haskell function accursedUnutterablePerformIO: accursedUnutterablePerformIO :: IO a -> a This "function" has a superficial similarity to unsafePerformIO but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet. Witness the trail of destruction: https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7 https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da https://github.com/haskell/aeson/commit/720b857e2e0acf2edc4f5512f2b217a89449a89d https://ghc.haskell.org/trac/ghc/ticket/3486 https://ghc.haskell.org/trac/ghc/ticket/3487 https://ghc.haskell.org/trac/ghc/ticket/7270 https://gitlab.haskell.org/ghc/ghc/-/issues/22204 Do not talk about "safe"! You do not know what is safe! Yield not to its blasphemous call! Flee traveller! Flee or you will be corrupted and devoured!

@abnv@fantastic.earth

Which is your favourite parsing library and why?

  • Parsec2 (25%)
  • ReadP0 (0%)
  • Attoparsec1 (13%)
  • Megaparsec4 (50%)
  • Alex + Happy0 (0%)
  • Flatparse1 (13%)
  • Earley0 (0%)
  • Parsley0 (0%)
  • Streamly0 (0%)
  • Polyparse0 (0%)
@pandoc@fosstodon.org

Pandoc is written in (haskell.org), an advanced, purely functional programming language. It was chosen for its great parser support, which was ahead of its time when pandoc was born in 2006. The language is also uniquely suited for a long-lived project, as the strong typing helps tremendously to keep things maintainable.

haskell.org

Haskell Language

The Haskell purely functional programming language home page.

@pandoc@fosstodon.org

Pandoc is written in (haskell.org), an advanced, purely functional programming language. It was chosen for its great parser support, which was ahead of its time when pandoc was born in 2006. The language is also uniquely suited for a long-lived project, as the strong typing helps tremendously to keep things maintainable.

haskell.org

Haskell Language

The Haskell purely functional programming language home page.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@haskell@fosstodon.org
@haskell@fosstodon.org
@haskell@fosstodon.org
@abnv@fantastic.earth

I've written a series of blog posts, in which I write a and a for arithmetic in . We explore the following topics in the series:

- Parsing arithmetic expressions to ASTs.
- Compiling ASTs to bytecode.
- Interpreting ASTs.
- Efficiently executing bytecode in a VM.
- Disassembling bytecode and decompiling opcodes for debugging and testing.
- Unit testing and property-based testing for our compiler and VM.
- Benchmarking our code to see how the different passes perform.
- All the while keeping an eye on performance.

The third and final post of the series that focuses on writing the virtual machine is now out: abhinavsarkar.net/posts/arithm

abhinavsarkar.net

A Fast Bytecode VM for Arithmetic: The Virtual Machine

We write a fast bytecode VM for arithmetic in Haskell.

@the@ultracrepidarian.mysteriar.ch

Why has no one written a Fediverse server in Haskell?

I would love to be wrong about this, obviously, but I've looked, and I can't find anything that speaks ActivityPub in Haskell.

Is Haskell just a bad language to use for something like this, and if so then why, or what's the reason if not that?

#Haskell #Fediverse

@lobsters@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@jnkrtech@treehouse.systems

I have an algebraic data type for an AST, which takes a type parameter for the type of expression that the AST holds. I’m writing a function which walks the AST, transforming certain nodes, but always keeping the types of the nodes the same. For example, I can provide this function a function for transforming identifiers (like for renaming them), but the transformer has to return another identifier. The outer structure of the AST stays the same. This is important because I only want to specify transformation functions for the “interesting” cases, and allow the majority of cases to use a default transformer which does nothing more than traverse down the node’s children.

What would you name such a thing? I wouldn’t call it “map” because it doesn’t change the type parameter. It’s not “fold” because it doesn’t have the ability to vary the return type at all. It might be a special case of some other morphism, which would be helpful, but I’m not seeing it.

@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@abnv@fantastic.earth
@haskell@fosstodon.org

It's ON!

fosstodon.org

ZuriHac (@zurihac@fosstodon.org)

ZuriHac 2026 - Registrations are open! ZuriHac is the biggest Haskell community event in the world: a completely free, three-day grassroots coding festival co-organized by the Zürich Friends of Haskell and the OST Eastern Switzerland University of Applied Science. It is not your standard conference with papers and presentations, but features fantastic keynotes, hands-on tracks, hacking on many of your favourite projects, and of course lots of socializing! Register now: https://zureg.zfoh.ch/register

@zurihac@fosstodon.org

ZuriHac 2026 - Registrations are open!

ZuriHac is the biggest Haskell community event in the world: a completely free, three-day grassroots coding festival co-organized by the Zürich Friends of Haskell and the OST Eastern Switzerland University of Applied Science. It is not your standard conference with papers and presentations, but features fantastic keynotes, hands-on tracks, hacking on many of your favourite projects, and of course lots of socializing!

Register now: zureg.zfoh.ch/register

zureg.zfoh.ch

Registration

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz

"Five-Point Haskell": Total depravity (and defensive typing). ~ Justin Le. blog.jle.im/entry/five-point-h

blog.jle.im

"Five-Point Haskell": Total Depravity (and Defensive Typing)

I have thought about distilling the principles by which I program Haskell, and how I’ve been able to steer long-lived projects over years of growth, refactorings, and changes in demands. I find myself coming back to a few distinct and helpful “points” (“doctrines”, if you may allow me to say) that have yet to lead me astray. With a new age of software development coming, what does it even mean to write good, robust, correct code? It is long overdue to clarify the mindset we use to define “good” coding principles. In this series, Five-Point Haskell, I’ll set out to establish a five-point framework for typed functional programming (and Haskell-derived) design that aims to produce code that is maintainable, correct, long-lasting, extensible, and beautiful to write and work with. We’ll reference real-world case studies with actual examples when we can, and also attempt to dispel thought-leader sound bites that have become all too popular on Twitter (“heresies”, so to speak). Let’s jump right into point 1: the doctrine of Total Depravity, and why Haskell is perfectly primed to make living with it as frictionless as possible. Total Depravity: If your code’s correctness depends on keeping complicated interconnected structure in your head, a devastating incident is not a matter of if but when.Therefore, delegate these concerns to tooling and a sufficiently powerful compiler, use types to guard against errors, and free yourself to only mentally track the actual important things.

@6d03@mathstodon.xyz
@6d03@mathstodon.xyz
@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@johl@mastodon.xyz

This is so niche and yet so relevant to my interests: "Kip is an experimental programming language that combines Turkish grammar rules with a type system. Case endings, vowel harmony, and other Turkish morphological features are an integral part of Kip's type-checking process."

github.com/kip-dili/kip/wiki/T

github.com

Tutorial

A programming language in Turkish where grammatical case and mood are part of the type system. - kip-dili/kip

@johl@mastodon.xyz

This is so niche and yet so relevant to my interests: "Kip is an experimental programming language that combines Turkish grammar rules with a type system. Case endings, vowel harmony, and other Turkish morphological features are an integral part of Kip's type-checking process."

github.com/kip-dili/kip/wiki/T

github.com

Tutorial

A programming language in Turkish where grammatical case and mood are part of the type system. - kip-dili/kip

@haskell@fosstodon.org
@abnv@fantastic.earth
@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@haskell@fosstodon.org
@DiazCarrete@hachyderm.io

Got so furious while trying to get this HasField instance to compile that I bashed my face against the keyboard, inserting letters like k s t u v m a b wholly at random. Lo and behold, now it typechecks:

Code that defines a "HasField" instance for the Optic type from the "optics-core" library. The idea is to be able use OverloadedRecordDot to compose optics, with the "the" identity optic as the start of the composition.

{-# LANGUAGE UndecidableInstances #-}
module Optics.Lens.Dot where

import GHC.Records
import GHC.TypeLits
import Optics.Core

instance
(GField (name :: Symbol) u v a b,
JoinKinds k A_Lens m,
AppendIndices is NoIx ks)
=>
HasField name (Optic k is s t u v) (Optic m ks s t a b) where
getField = (% gfield @name)

the :: Iso a b a b
the = equality
ALT text

Code that defines a "HasField" instance for the Optic type from the "optics-core" library. The idea is to be able use OverloadedRecordDot to compose optics, with the "the" identity optic as the start of the composition. {-# LANGUAGE UndecidableInstances #-} module Optics.Lens.Dot where import GHC.Records import GHC.TypeLits import Optics.Core instance (GField (name :: Symbol) u v a b, JoinKinds k A_Lens m, AppendIndices is NoIx ks) => HasField name (Optic k is s t u v) (Optic m ks s t a b) where getField = (% gfield @name) the :: Iso a b a b the = equality

@AmenZwa@mathstodon.xyz

"Write Yourself a Scheme in 48 Hours: An Introduction to Haskell through Example", Tang (2007)

upload.wikimedia.org/wikipedia

I'm well and truly miffed—until this moment, I'd never come across this little jewel of a free ebook.🤦‍♂️

This book teaches practical (like monadic parsing) through an implementation of a large subset of R5RS interpreter, all in just 138 pp. An experienced FP , even one who is unfamiliar with Haskell and Scheme (although I’ve not met such a person), can plough through this text, in one sitting.

It's brilliant!

@Jose_A_Alonso@mathstodon.xyz
@AmenZwa@mathstodon.xyz

"Write Yourself a Scheme in 48 Hours: An Introduction to Haskell through Example", Tang (2007)

upload.wikimedia.org/wikipedia

I'm well and truly miffed—until this moment, I'd never come across this little jewel of a free ebook.🤦‍♂️

This book teaches practical (like monadic parsing) through an implementation of a large subset of R5RS interpreter, all in just 138 pp. An experienced FP , even one who is unfamiliar with Haskell and Scheme (although I’ve not met such a person), can plough through this text, in one sitting.

It's brilliant!

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz

Advent of Code 2025: Haskell solution reflections for all 12 days. ~ Justin Le. blog.jle.im/entry/advent-of-co

blog.jle.im

Advent of Code 2025: Haskell Solution Reflections for all 12 Days

Merry Christmas all! This is my annual Advent of Code post! Advent of Code is a series of (this year) 12 daily Christmas-themed programming puzzles that are meant to be fun diversions from your daily life, help you find a bit of whimsy in your world, give you a chance to explore new ideas and program together with your friends. I always enjoy discussing creative ways to solve these puzzles every day, and it’s become a bit of an annual highlight for me and a lot of others. My favorite part about these puzzles is that they are open ended enough that there are usually many different interesting ways to solve them — it’s not like a stressful interview question where you have to recite the obscure incantation to pass the test. In the past I’ve leveraged group theory, galilean transformations and linear algebra, and more group theory. Haskell is especially fun for these because if you set up your abstractions in just the right way, the puzzles seem to solve themselves. It’s a good opportunity every year to get exposed to different parts of the Haskell ecosystem! Last year, I moved almost all of my Haskell code to an Advent of Code Megarepo, and I also write up my favorite ways to solve each one in the megarepo wiki. All of this year’s 12 puzzles are here, but I’ve also included links to each individual one in this post. I’m also considering expanding some of these into full on blog posts, so be on the look out, or let me know if there are any that you might want fully expanded! And if you haven’t, why not try these out yourself? Be sure to drop by the libera-chat ##advent-of-code channel to discuss any fun ways you solve them, or any questions! Thanks again to Eric for a great new fresh take on the event this year! * Day 1 - Secret Entrance — The classic Day 1 scanl * Day 2 - Gift Shop — The super efficient IntSet * Day 3 - Lobby — StateT + [] = backtracking search monad * Day 4 - Printing Department — 2D cellular automata * Day 5 - Cafeteria — The power of the data-interval library * Day 6 - Trash Compactor — Data.List manipulations * Day 7 - Laboratories — Tying the knot * Day 8 - Playground — Iterative Clustering * Day 9 - Movie Theater — IntervalSet and IntervalMap * Day 10 - Factory — Guassian Elimation, Type-safe Mutable Vectors * Day 11 - Reactor — More Knot Tying and DP! * Day 12 - Christmas Tree Farm — Counting

@kaleissin@wandering.shop

Running a program (or trying to) is very late 90's nostalgic, very

configure && make && make install

.. then wait for 16 hours and realize it failed after 14 of them. The error messages was easier to understand in the 90's though, and autoconf fixed a lot of shite.

@haskell@fosstodon.org
@6d03@mathstodon.xyz

I have a working prototype of an to compiler. It can't do a lot yet; but it does translate enum types.

(Built on top of a lot of great existing work.)

```
ghci> Prelude.putStr =<< Prelude.readFile "./asn1-modules/bar.asn1"
BarFramework { 1 }

DEFINITIONS ::=
BEGIN

Bar ::= ENUMERATED {red, blue, yellow}

END -- BarFramework
ghci> _ = () ; $(spliceFromModuleOrDie "./asn1-modules/bar.asn1")
ghci> :i Bar
type Bar :: *
data Bar = Red | Blue | Yellow
-- Defined at <interactive>:137:11
ghci>
```

@kosmikus@functional.cafe
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org

Saint-Exupéry wrote “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

What would you like to see removed from to help it achieve perfection?

@haskell@fosstodon.org

Saint-Exupéry wrote “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

What would you like to see removed from to help it achieve perfection?

@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@jonocarroll@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@pandoc@fosstodon.org

Pandoc allows to access and modify the Haskell runtime system (RTS) that the program runs on.

E.g., to print memory usage:

pandoc +RTS -s -RTS …

Or to limit the maximum heap size available to pandoc to 2 GB:

pandoc +RTS -M2G -RTS …

See all available options by running:

pandoc +RTS -?

This can be helpful when facing performance issues.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@kosmikus@functional.cafe
@abnv@fantastic.earth

Would people be interested in a series of posts where I implement the C from "Writing a C Compiler" book by Nora Sandler in ? I'd focus on Haskell specific libraries and techniques with some additional bits not present in the book.

  • Yes21 (84%)
  • No3 (12%)
  • I hate book implementations1 (4%)
@Jose_A_Alonso@mathstodon.xyz
@hackuador@functional.cafe

Great lineup for Brisbane Functional Programming Group next Tuesday November 11!

- Serializotron: zero-boilerplate serialisation for (Carlo Hamalainen)
- tmefunc: syntactic sugar for in (T. Mark Ellison and Siva Kalyan)

luma.com/kq933nnz

This is our final regular session for 2025, with a social event planned for December. Be there or be a lambda cube!

luma.com

BFPG Meetup - November 2025 - Serializotron + FP in Python · Luma

Join the BFPG Discord: https://discord.gg/yYz2d8w7FY Agenda 18:00: Welcome and setup Presentation #1: Serializotron: Protobuf‑Backed, Zero‑Boilerplate…

@abnv@fantastic.earth · Reply to Abhinav 🧭

Interesting poll results! I didn't expect Attoparsec to go toe-to-toe with Megaparsec.

So I did some digging into based programming language projects on Github, and here's what I found (lexer and parser mentioned separately, if different):

- Purescript: handwritten + Happy
- Elm: handwritten
- Agda: Alex + Happy
- Dex: Megaparsec
- Carp: Parsec
- Dhall: Megaparsec
- Grace: Megaparsec + Earley
- Plutus: Megaparsec
- Grin: Megaparsec
- Futhark: Alex + Happy
- Granule / Gerty: Alex + Happy
- Kaleidoscope: Parsec
- Egison: Megaparsec
- Amulet: Alex + Happy
- Paskell: Parsec
- Facet: Handwritten + Parsec
- Eclair: Megaparsec
- Olifant: Megaparsec
- Shellcheck: Parsec
- Nixfmt: Megaparsec

It seems like Megaparsec is the clear winner when it comes to parsing programming languages in Haskell. However, if I focus on projects that parse file formats and network protocols, Attoparsec is the most popular one.

@abnv@fantastic.earth · Reply to Abhinav 🧭

Interesting poll results! I didn't expect Attoparsec to go toe-to-toe with Megaparsec.

So I did some digging into based programming language projects on Github, and here's what I found (lexer and parser mentioned separately, if different):

- Purescript: handwritten + Happy
- Elm: handwritten
- Agda: Alex + Happy
- Dex: Megaparsec
- Carp: Parsec
- Dhall: Megaparsec
- Grace: Megaparsec + Earley
- Plutus: Megaparsec
- Grin: Megaparsec
- Futhark: Alex + Happy
- Granule / Gerty: Alex + Happy
- Kaleidoscope: Parsec
- Egison: Megaparsec
- Amulet: Alex + Happy
- Paskell: Parsec
- Facet: Handwritten + Parsec
- Eclair: Megaparsec
- Olifant: Megaparsec
- Shellcheck: Parsec
- Nixfmt: Megaparsec

It seems like Megaparsec is the clear winner when it comes to parsing programming languages in Haskell. However, if I focus on projects that parse file formats and network protocols, Attoparsec is the most popular one.

@abnv@fantastic.earth · Reply to Abhinav 🧭

Interesting poll results! I didn't expect Attoparsec to go toe-to-toe with Megaparsec.

So I did some digging into based programming language projects on Github, and here's what I found (lexer and parser mentioned separately, if different):

- Purescript: handwritten + Happy
- Elm: handwritten
- Agda: Alex + Happy
- Dex: Megaparsec
- Carp: Parsec
- Dhall: Megaparsec
- Grace: Megaparsec + Earley
- Plutus: Megaparsec
- Grin: Megaparsec
- Futhark: Alex + Happy
- Granule / Gerty: Alex + Happy
- Kaleidoscope: Parsec
- Egison: Megaparsec
- Amulet: Alex + Happy
- Paskell: Parsec
- Facet: Handwritten + Parsec
- Eclair: Megaparsec
- Olifant: Megaparsec
- Shellcheck: Parsec
- Nixfmt: Megaparsec

It seems like Megaparsec is the clear winner when it comes to parsing programming languages in Haskell. However, if I focus on projects that parse file formats and network protocols, Attoparsec is the most popular one.

@abnv@fantastic.earth · Reply to Abhinav 🧭

Interesting poll results! I didn't expect Attoparsec to go toe-to-toe with Megaparsec.

So I did some digging into based programming language projects on Github, and here's what I found (lexer and parser mentioned separately, if different):

- Purescript: handwritten + Happy
- Elm: handwritten
- Agda: Alex + Happy
- Dex: Megaparsec
- Carp: Parsec
- Dhall: Megaparsec
- Grace: Megaparsec + Earley
- Plutus: Megaparsec
- Grin: Megaparsec
- Futhark: Alex + Happy
- Granule / Gerty: Alex + Happy
- Kaleidoscope: Parsec
- Egison: Megaparsec
- Amulet: Alex + Happy
- Paskell: Parsec
- Facet: Handwritten + Parsec
- Eclair: Megaparsec
- Olifant: Megaparsec
- Shellcheck: Parsec
- Nixfmt: Megaparsec

It seems like Megaparsec is the clear winner when it comes to parsing programming languages in Haskell. However, if I focus on projects that parse file formats and network protocols, Attoparsec is the most popular one.

@abnv@fantastic.earth

Which is your favourite parsing library and why?

  • Parsec2 (25%)
  • ReadP0 (0%)
  • Attoparsec1 (13%)
  • Megaparsec4 (50%)
  • Alex + Happy0 (0%)
  • Flatparse1 (13%)
  • Earley0 (0%)
  • Parsley0 (0%)
  • Streamly0 (0%)
  • Polyparse0 (0%)
@Jose_A_Alonso@mathstodon.xyz
@abnv@fantastic.earth

Which is your favourite parsing library and why?

  • Parsec2 (25%)
  • ReadP0 (0%)
  • Attoparsec1 (13%)
  • Megaparsec4 (50%)
  • Alex + Happy0 (0%)
  • Flatparse1 (13%)
  • Earley0 (0%)
  • Parsley0 (0%)
  • Streamly0 (0%)
  • Polyparse0 (0%)
@Jose_A_Alonso@mathstodon.xyz
@bgamari@mastodon.social

After a long wait, GHC 9.14.1-rc1 is now available. This includes an important fix which ensures compatibility with macOS 26 and later. We expect that this same fix will be backported to GHC 9.12 and 9.10 in the coming months.

Happy Haskelling!

https:/ /www.haskell.org/ghc/blog/20251030-ghc-9.14.1-rc1-released.html

@bgamari@mastodon.social

After a long wait, GHC 9.14.1-rc1 is now available. This includes an important fix which ensures compatibility with macOS 26 and later. We expect that this same fix will be backported to GHC 9.12 and 9.10 in the coming months.

Happy Haskelling!

https:/ /www.haskell.org/ghc/blog/20251030-ghc-9.14.1-rc1-released.html

@Jose_A_Alonso@mathstodon.xyz
@kosmikus@functional.cafe
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@abnv@fantastic.earth

I've written a series of blog posts, in which I write a and a for arithmetic in . We explore the following topics in the series:

- Parsing arithmetic expressions to ASTs.
- Compiling ASTs to bytecode.
- Interpreting ASTs.
- Efficiently executing bytecode in a VM.
- Disassembling bytecode and decompiling opcodes for debugging and testing.
- Unit testing and property-based testing for our compiler and VM.
- Benchmarking our code to see how the different passes perform.
- All the while keeping an eye on performance.

The third and final post of the series that focuses on writing the virtual machine is now out: abhinavsarkar.net/posts/arithm

abhinavsarkar.net

A Fast Bytecode VM for Arithmetic: The Virtual Machine

We write a fast bytecode VM for arithmetic in Haskell.

@Jose_A_Alonso@mathstodon.xyz
@DiazCarrete@hachyderm.io
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@kosmikus@functional.cafe
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@pandoc@fosstodon.org

Looking for a LaTeX symbol, but don't know the command to produce it?
detexify.kirelabs.org can help. Draw the symbol, and the app will produce a list of matching symbols.

Incidentally, the tool is written in , just like .

Video showing a how the partial differential symbol ∂ is drawn in a box (badly), and with the tool responding with a list of LaTeX commands after a short wait.
ALT text

Video showing a how the partial differential symbol ∂ is drawn in a box (badly), and with the tool responding with a list of LaTeX commands after a short wait.

Video showing a how the partial differential symbol ∂ is drawn in a box (badly), and with the tool responding with a list of LaTeX commands after a short wait.
ALT text

Video showing a how the partial differential symbol ∂ is drawn in a box (badly), and with the tool responding with a list of LaTeX commands after a short wait.

@pandoc@fosstodon.org

Looking for a LaTeX symbol, but don't know the command to produce it?
detexify.kirelabs.org can help. Draw the symbol, and the app will produce a list of matching symbols.

Incidentally, the tool is written in , just like .

Video showing a how the partial differential symbol ∂ is drawn in a box (badly), and with the tool responding with a list of LaTeX commands after a short wait.
ALT text

Video showing a how the partial differential symbol ∂ is drawn in a box (badly), and with the tool responding with a list of LaTeX commands after a short wait.

Video showing a how the partial differential symbol ∂ is drawn in a box (badly), and with the tool responding with a list of LaTeX commands after a short wait.
ALT text

Video showing a how the partial differential symbol ∂ is drawn in a box (badly), and with the tool responding with a list of LaTeX commands after a short wait.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@DiazCarrete@hachyderm.io
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@byorgey@mathstodon.xyz

The folks at finally published the problems from a bunch of old contests that they have hosted over the years, including quite a few that I helped organize. Yay! (I have been bugging them to do this literally for years.) In particular, the list of available problems written by me instantly went from 2 to about 35:

open.kattis.com/problem-author

I have solved many (though not all) of them in . Give them a try and let me know what you think! 😄

open.kattis.com

Problems by Brent Yorgey – Kattis, Kattis

@hackuador@functional.cafe

Two AMAZING talks for the Brisbane Functional Programming Group September 9th meetup:

• ​Typed Holes and Hole-driven Development (George Wilson)
• ​'s Type-Safe OTP Concurrency: A New Era of Reliable Distributed Programming (Cameron Badman)

luma.com/kukbikp7

lu.ma

BFPG Meetup - September 2025 - Hole-driven development + Gleam · Luma

Join the BFPG Discord: https://discord.gg/yYz2d8w7FY Agenda 18:00: Welcome and setup Presentation #1: Typed Holes and Hole-driven Development - George…

@byorgey@mathstodon.xyz

The folks at finally published the problems from a bunch of old contests that they have hosted over the years, including quite a few that I helped organize. Yay! (I have been bugging them to do this literally for years.) In particular, the list of available problems written by me instantly went from 2 to about 35:

open.kattis.com/problem-author

I have solved many (though not all) of them in . Give them a try and let me know what you think! 😄

open.kattis.com

Problems by Brent Yorgey – Kattis, Kattis

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@abnv@fantastic.earth

I'm writing a series of blog posts, in which I write a and a for arithmetic in . We explore the following topics in the series:

- Parsing arithmetic expressions to ASTs.
- Compiling ASTs to bytecode.
- Interpreting ASTs.
- Efficiently executing bytecode in a VM.
- Disassembling bytecode and decompiling opcodes for debugging and testing.
- Unit testing and property-based testing for our compiler and VM.
- Benchmarking our code to see how the different passes perform.
- All the while keeping an eye on performance.

The second post of the series that focuses on writing the is now out: abhinavsarkar.net/posts/arithm

abhinavsarkar.net

A Fast Bytecode VM for Arithmetic: The Compiler

We write a fast bytecode VM for arithmetic in Haskell.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@hackuador@functional.cafe
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@DiazCarrete@hachyderm.io

"Overloading harms type inference, so undesirable"

"OverloadedLists harms hole-driven development."

youtube.com/watch?v=CCDz-_aq5g

I wonder what the presenter thinks about the QualifiedLiterals GHC proposal github.com/ghc-proposals/ghc-p In a way, that proposal aims to tame Overloaded-type extensions.

Slide with the line "Overloading harms type inference, so undesirable"
ALT text

Slide with the line "Overloading harms type inference, so undesirable"

A slide with the title "OverloadedLists" harms hole-driven development.
ALT text

A slide with the title "OverloadedLists" harms hole-driven development.

@abnv@fantastic.earth

I'm starting a series of blog posts, in which I write a and a for arithmetic in . We explore the following topics in the series:

- Parsing arithmetic expressions to ASTs.
- Compiling ASTs to bytecode.
- Interpreting ASTs.
- Efficiently executing bytecode in a VM.
- Disassembling bytecode and decompiling opcodes for debugging and testing.
- Unit testing and property-based testing for our compiler and VM.
- Benchmarking our code to see how the different passes perform.
- All the while keeping an eye on performance.

The first post of the series that focuses on writing the is now out: abhinavsarkar.net/posts/arithm

abhinavsarkar.net

A Fast Bytecode VM for Arithmetic: The Parser

We write a fast bytecode VM for arithmetic in Haskell.

@Jose_A_Alonso@mathstodon.xyz

Fixed-point-oriented programming: A concise and elegant paradigm. ~ Yong Qi Foo, Brian Sze-Kai Cheong, Michael D. Adams. arxiv.org/abs/2507.21439v1

arxiv.org

Fixed-Point-Oriented Programming: A Concise and Elegant Paradigm

Fixed-Point-Oriented Programming (FPOP) is an emerging paradigm designed to streamline the implementation of problems involving self-referential computations. These include graph algorithms, static analysis, parsing, and distributed computing-domains that traditionally require complex and tricky-to-implement work-queue algorithms. Existing programming paradigms lack direct support for these inherently fixed-point computations, leading to inefficient and error-prone implementations. This white paper explores the potential of the FPOP paradigm, which offers a high-level abstraction that enables concise and expressive problem formulations. By leveraging structured inference rules and user-directed optimizations, FPOP allows developers to write declarative specifications while the compiler ensures efficient execution. It not only reduces implementation complexity for programmers but also enhances adaptability, making it easier for programmers to explore alternative solutions and optimizations without modifying the core logic of their program. We demonstrate how FPOP simplifies algorithm implementation, improves maintainability, and enables rapid prototyping by allowing problems to be clearly and concisely expressed. For example, the graph distance problem can be expressed in only two executable lines of code with FPOP, while it takes an order of magnitude more code in other paradigms. By bridging the gap between theoretical fixed-point formulations and practical implementations, we aim to foster further research and adoption of this paradigm.

@hackuador@functional.cafe
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz

Formally verified suffix array construction (in Isabelle/HOL). ~ Louis Cheung, Alistair Moffat, Christine Rizkallah. link.springer.com/article/10.1

link.springer.com

Formally Verified Suffix Array Construction - Journal of Automated Reasoning

Suffix arrays are a data structure with numerous real-world applications. They are extensively used in text retrieval and data compression applications, including query suggestion mechanisms in web search, and in bioinformatics tools for DNA sequencing and matching. This wide applicability means that algorithms for constructing suffix arrays are of great practical importance. The SA-IS algorithm is an efficient but conceptually complex suffix array construction technique, and implementing it requires a deep understanding of its underlying theory. As a critical step towards developing a provably correct and efficient implementation, we have developed the SA-IS algorithm in Isabelle/HOL and formally verified that it is equivalent to a mathematical functional specification of suffix arrays, a task that required verifying a wide range of underlying properties of strings and suffixes. We also used Isabelle’s code extraction facilities to extract an executable Haskell implementation of SA-IS, which albeit is inefficient due to using lists and natural numbers rather than arrays and machine words, demonstrates that our verified HOL implementation of SA-IS can be refined to an executable implementation in its current form.

@kakkun61@pawoo.net · Reply to kakkun61.com
@kakkun61@pawoo.net · Reply to kakkun61.com
@kakkun61@pawoo.net

あの『モナドドリル』が、ウェブでも印刷版を買えるようになりました! 注文されたら @kakkun61 がちまちま梱包して郵送に出します! 他の同人誌も1週間をめどに追加予定です kakkun61.booth.pm/items/722235

kakkun61.booth.pm

モナドドリル - 趣味はデバッグ…… - BOOTH

モナドの読解力と利用力がつく! 印刷版には PDF が付属します。

@Jose_A_Alonso@mathstodon.xyz
@pmidden@fosstodon.org

pretty print structured data, recommendations? I currently recurse over my structure, tracking indentation level. Works, but is definitely a little clumsy.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@DiazCarrete@hachyderm.io

Suffering from the scourge of insomnia? Want to fall asleep to the sounds of a Haskell application being assembled component by component?

If so, you're in luck. In this 1-hour video I give a demo of how to use the "cauldron" library to wire all the components of a Haskell application at the composition root.

youtube.com/watch?v=9ZJLK0iM-2

youtube.com

Dependency injection in Haskell: wiring you application using "cauldron"

This is an example of how to use the "cauldron" library for wiring a small Haskell application. The application is structured as a bunch of records-of-functi...

@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@haskell@fosstodon.org
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org
@kosmikus@functional.cafe
@haskell@fosstodon.org
@haskell_foundation@mastodon.social
@haskell_foundation@mastodon.social
@haskell@fosstodon.org
@teixi@mastodon.social · Reply to Marcel Fröhlich
@teixi@mastodon.social · Reply to Marcel Fröhlich
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@momo@woof.tech

mreeow! Hi! My name is Momo! I'm a transfemme, and she/they is my preferred pronouns.

I code as a hobby in and . I also use as my main daily driver since last year. :blobfoxcomputer: :nkoLove:

I enjoy creating casual game mods in my free time, including Stardew Valley, , and various other games. :apartyblobcat:

I also love playing Cataclysm: Bright Nights () and Valley. Sometimes, , and too, because why not? I like the look and feel of these games. :blobcat3c:

During the weekends, I try to finish reading a fantasy book or two, if I'm feeling reaaaaally cozy :blobcattea: :blobcatmorningtea:

I will be posting about techy stuff that I encounter (mainly and ), share my gaming experiences, and rant about random things, ranging from politics to personal life.

And I like to sip a cup of coffee while watching camping videos, too, for some reason. :blabfox:

Feel free to follow me if you want to hear more of my blabbing! :blobcat_mlem: :blobcat_nwn:

PS: I will put distressing or NSFW posts behind CW. :blobcatpeek:

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@kosmikus@functional.cafe
@Jose_A_Alonso@mathstodon.xyz
@DiazCarrete@hachyderm.io
Haskell code that gives newtype wrappers to the "Application" and "Middleware" type synonyms from module Network.Wai. Also, a DerivingVia-derived Monoid instance for the Middleware newtype that composes left-to-right.
ALT text

Haskell code that gives newtype wrappers to the "Application" and "Middleware" type synonyms from module Network.Wai. Also, a DerivingVia-derived Monoid instance for the Middleware newtype that composes left-to-right.

@Jose_A_Alonso@mathstodon.xyz
@DiazCarrete@hachyderm.io
@Jose_A_Alonso@mathstodon.xyz
@pmidden@fosstodon.org

I've surprised myself how fun it is to write this pure parser. It's, in a way, gruesome, fiddling with raw bytes, guessing some details, getting new files with features still unsupported, and I have no clue how exciting it will be to implement all the common filters. But the language is delightful and I'm making constant glacial progress. That accounts for a lot I suppose...

@DiazCarrete@hachyderm.io
@AndrzejWasowski@social.itu.dk

I am using one tool implemented in Haskell. Cost: my updates about 100 packages every 2 days on average. Seriously? I am starting to think that even though I am a programmer, programming in Haskell would not be for me - and not for the ferocious purity and laziness, but for the stability of the environment!

Disclaimer: I know nothing about the Haskell ecosystem. It may well be that these updates are just as innocuous as they are irritating.

@abnv@fantastic.earth
@pmidden@fosstodon.org · Reply to Brent Yorgey

@byorgey And here's me, about to give a tutorial and on the way to work, thinking that I should definitely mention that "IO" is different than "Maybe", "List", ... because in what way would "IO String" be a container"?

Good to have come to the same conclusion.

@haskell@fosstodon.org

Picking up is not a matter of "If" but of "When".

When your head overflows with UML diagrams instead of expressive yet concise types?

When your systems belch runtime exceptions like a Weezing?

When shared mutable state prevents you from understanding what the hell is happening?

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@BoydStephenSmithJr@hachyderm.io

Just put in another application via so I also wanted to try to get again.

I've been a programmer since 1985 (as a child), I've been an IT professional since 1995 (pulling wires and swapping cards and configuring MS Windows). I graduated from University of Arkansas Fayetteville with a BS in CS in December of 2003. A full resume is available.

I currently require a 100% remote position. I cannot relocate from Cove, .

I prefer something where I can be a high-performing individual contributor: reading, writing and improving source text the majority of my day, with some time spent knowledge-sharing with other developers -- learning and teaching. I'd like to work with , , or as the primary source language, but I can be productive in almost any language (no PHP, please; I promised myself never again).

I would prefer W-2 employment with a base salary of at least 130k USD/yr, plus some sort of retirement offering (401k or similar) and healthcare benefits (HDCP + HSA or similar).

(Boosts appreciated.)

@BoydStephenSmithJr@hachyderm.io

Just put in another application via so I also wanted to try to get again.

I've been a programmer since 1985 (as a child), I've been an IT professional since 1995 (pulling wires and swapping cards and configuring MS Windows). I graduated from University of Arkansas Fayetteville with a BS in CS in December of 2003. A full resume is available.

I currently require a 100% remote position. I cannot relocate from Cove, .

I prefer something where I can be a high-performing individual contributor: reading, writing and improving source text the majority of my day, with some time spent knowledge-sharing with other developers -- learning and teaching. I'd like to work with , , or as the primary source language, but I can be productive in almost any language (no PHP, please; I promised myself never again).

I would prefer W-2 employment with a base salary of at least 130k USD/yr, plus some sort of retirement offering (401k or similar) and healthcare benefits (HDCP + HSA or similar).

(Boosts appreciated.)

@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@voyd@nullptr.rehab

"Look, I don't think there's anything wrong with programming in or , but you should probably switch to when you hit like 3 or 4 months of experience

@pmidden@fosstodon.org

Am I correct in assuming that in , parsing a huge file with attoparsec is a bad idea, because the memory footprint will be equally huge?

Is there an alternative?

@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@mathr@post.lurk.org · Reply to Syntə

today (thanks to augustss fixing some MicroHs bugs) I managed to get tidal-core working in MicroHs!

this is just the pattern language, not including live scheduler, OSC message sending, etc.

The next step is to combine this toot with previous toot and have a Tidal/Haskell thing running inside a web browser. But there's a lot of rest of owl before that will do anything useful.

I pushed my branch to Microsoft Github for ease of review:
github.com/claudeha/Tidal/tree

@synte

dark mode terminal showing someone who doesn't know tidal's module structure trying to run a pattern.

the cool part is that it's using MicroHs instead of GHC.
ALT text

dark mode terminal showing someone who doesn't know tidal's module structure trying to run a pattern. the cool part is that it's using MicroHs instead of GHC.

@mathr@post.lurk.org · Reply to Syntə

today (thanks to augustss fixing some MicroHs bugs) I managed to get tidal-core working in MicroHs!

this is just the pattern language, not including live scheduler, OSC message sending, etc.

The next step is to combine this toot with previous toot and have a Tidal/Haskell thing running inside a web browser. But there's a lot of rest of owl before that will do anything useful.

I pushed my branch to Microsoft Github for ease of review:
github.com/claudeha/Tidal/tree

@synte

dark mode terminal showing someone who doesn't know tidal's module structure trying to run a pattern.

the cool part is that it's using MicroHs instead of GHC.
ALT text

dark mode terminal showing someone who doesn't know tidal's module structure trying to run a pattern. the cool part is that it's using MicroHs instead of GHC.

@mathr@post.lurk.org

seems I somehow got interpreter compiled and working in a browser using

used a require.js I found online (from Tarp pixelsvsbytes.com/2013/02/js-r ) and slighly patched for my use case / url layout, and some minimal folder (npm install --save path) with custom symlinks inside to choose the browser js.

the HTML from Emscripten is patched lightly to add the require script and a couple of require() calls. the standard library is included with preload file; the total size of the served folder is about 3.5MB.

the usability is terrible (have to enter input in a modal form with no history or completion etc, output goes to browser console) but it's a start!

desktop screenshot of firefox open at localhost : 8080 / mhs.html

there is a large Input: modal dialog, behind which is a default Emscripten HTML page.

mhs welcome banner is visible in the emscripten text area, but subsequent input and output is only echoed in the browser developer tools console, visible at the bottom, where you can see "hello world" and factorials from 1 to 10.
ALT text

desktop screenshot of firefox open at localhost : 8080 / mhs.html there is a large Input: modal dialog, behind which is a default Emscripten HTML page. mhs welcome banner is visible in the emscripten text area, but subsequent input and output is only echoed in the browser developer tools console, visible at the bottom, where you can see "hello world" and factorials from 1 to 10.

@Jose_A_Alonso@mathstodon.xyz
@maralorn@chaos.social

I will be teaching the track at 🇨🇭 ⛰️

zfoh.ch/zurihac2025/

Looking forward to showing you all the best(TM) way to setup packages with Nix 😎 Maybe we can even upstream some Haskell packages to ? 😆

I jumped in a bit on short notice and am still collecting ideas. So let me know what you would like to learn!

zfoh.ch

ZuriHac 2025

ZuriHac is a free annual Haskell event brought to you by «Zürich Friends of Haskell»

@abnv@fantastic.earth

It is a good day to unleash the agent of chaos.

Screenshot of the documentation of the Haskell function accursedUnutterablePerformIO:

accursedUnutterablePerformIO :: IO a -> a

This "function" has a superficial similarity to unsafePerformIO but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet.

Witness the trail of destruction:

    https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7
    https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da
    https://github.com/haskell/aeson/commit/720b857e2e0acf2edc4f5512f2b217a89449a89d
    https://ghc.haskell.org/trac/ghc/ticket/3486
    https://ghc.haskell.org/trac/ghc/ticket/3487
    https://ghc.haskell.org/trac/ghc/ticket/7270
    https://gitlab.haskell.org/ghc/ghc/-/issues/22204

Do not talk about "safe"! You do not know what is safe!

Yield not to its blasphemous call! Flee traveller! Flee or you will be corrupted and devoured!
ALT text

Screenshot of the documentation of the Haskell function accursedUnutterablePerformIO: accursedUnutterablePerformIO :: IO a -> a This "function" has a superficial similarity to unsafePerformIO but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet. Witness the trail of destruction: https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7 https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da https://github.com/haskell/aeson/commit/720b857e2e0acf2edc4f5512f2b217a89449a89d https://ghc.haskell.org/trac/ghc/ticket/3486 https://ghc.haskell.org/trac/ghc/ticket/3487 https://ghc.haskell.org/trac/ghc/ticket/7270 https://gitlab.haskell.org/ghc/ghc/-/issues/22204 Do not talk about "safe"! You do not know what is safe! Yield not to its blasphemous call! Flee traveller! Flee or you will be corrupted and devoured!

@maralorn@chaos.social

I will be teaching the track at 🇨🇭 ⛰️

zfoh.ch/zurihac2025/

Looking forward to showing you all the best(TM) way to setup packages with Nix 😎 Maybe we can even upstream some Haskell packages to ? 😆

I jumped in a bit on short notice and am still collecting ideas. So let me know what you would like to learn!

zfoh.ch

ZuriHac 2025

ZuriHac is a free annual Haskell event brought to you by «Zürich Friends of Haskell»

@haskell_discussions@mastodon.social
@abnv@fantastic.earth

is dying so it's appropriate to talk about the minimal service I wrote for myself: LinkFodder.

You can save links via an API, or a form, or a Telegram bot, and you get an HTML page (shown below) and an Atom . That’s it.

Supports multiple users, written in , deployable as a single binary (or a Docker image) behind the reverse-proxy server of your choice in your setup.

It doesn't even need a database to run; it simply rewrites the HTML and Atom files when you save a new link.

Screenshot of Linkfodder page for me. Shows number of links saved, time for last update, and two latest links. Also shows a form to save URLs, and a link to a feed of links.
ALT text

Screenshot of Linkfodder page for me. Shows number of links saved, time for last update, and two latest links. Also shows a form to save URLs, and a link to a feed of links.

@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@DiazCarrete@hachyderm.io
@das_g@chaos.social · Reply to Ramin Honary
@das_g@chaos.social · Reply to Ramin Honary
@haskell_discussions@mastodon.social
@ramin_hal9001@fe.disroot.org · Reply to das-g

@das_g True. It is certainly magical that there is a programming language which defines a state monad called “IO” (or sometimes “Effect”) which carries around with it a symbol of the entire Real World in order to model the idea that any evaluation of a function of that type of monad may (or may not) create a change somewhere out in the real world, as opposed to “pure” functions which can only ever manipulate the stack.

#tech #software #Haskell #ProgrammingLanguage #TypeTheory #CategoryTheory

fe.disroot.org

FEDIsroot

@das_g@chaos.social
@DiazCarrete@hachyderm.io

In Haskell, the humble dot . can have several meanings.

- The composition operator hackage.haskell.org/package/ba

- Module separator haskell.org/onlinereport/haske

- With OverloadedRecordDot, field access downloads.haskell.org/ghc/late

First one doesn't cause problems as long as you do the right thing and always surround it with spaces.

The last two can suffer from ambiguity. Are we referring to a qualified value, or (admittedly a rare thing) accessing a field on a datatype constructor?

To resolve the ambiguity, parentheses seem to be enough.

This kind of ambiguity might also happen with the QualifiedDo extension downloads.haskell.org/ghc/late and (if it gets accepted 🤞) the QualifiedLiterals extension github.com/ghc-proposals/ghc-p

Haskell code that fails to compile because GHC assumes "Xoo1.xofi" is a module-qualified name.

data Xoo = Xoo1 | Xoo2 

instance HasField "xofi" Xoo String where
    getField _ = "xofi"

xooo2 :: String
xooo2 = Xoo1.xofi
ALT text

Haskell code that fails to compile because GHC assumes "Xoo1.xofi" is a module-qualified name. data Xoo = Xoo1 | Xoo2 instance HasField "xofi" Xoo String where getField _ = "xofi" xooo2 :: String xooo2 = Xoo1.xofi

Same code as before, corrected by putting parentheses around the Xooo1 constructor.

data Xoo = Xoo1 | Xoo2 

instance HasField "xofi" Xoo String where
    getField _ = "xofi"

xooo2 :: String
xooo2 = (Xoo1).xofi
ALT text

Same code as before, corrected by putting parentheses around the Xooo1 constructor. data Xoo = Xoo1 | Xoo2 instance HasField "xofi" Xoo String where getField _ = "xofi" xooo2 :: String xooo2 = (Xoo1).xofi

@pmidden@fosstodon.org

I'm using 's excellent GitHub workflow to produce statically linked Haskell binaries. It's curious, however, that ghc-9.0.4 produces a binary that's roughly 1MiB in size, whereas 9.4 produces a whopping 30MiB binary. Haven't tested the later ghc versions yet, but I hope they're a bit more conservative w.r.t. size...

@jesper@agda.club
and they told me the perfect function name didn't exist..

#Haskell #Lens
The Haddock documentation for the function `confusing` from the Haskell Lens library. It is indeed confusing.
ALT text

The Haddock documentation for the function `confusing` from the Haskell Lens library. It is indeed confusing.

@pmidden@fosstodon.org

Typical packaging situation. I want to decompress a zip file. I search hackage for "zip". Lots of results. The first two are "zip" and "zip-archive". Similar amount of downloads, similar "Last U/L" date. What the hell do I use here? :D I'm now going by number of downloads, where "zip-archive" is the clear winner.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@kosmikus@functional.cafe

Is it just me, or is this a weird post by Sandy Maguire?

The Maybe formulation is incorrect -

`unionWith :: (Maybe a -> Maybe b -> c) -> Map k a -> Map k b -> Map k c`

And that the version with `These` is the right one to use -

`unionWith :: (These a b -> c) -> Map k a -> Map k b -> Map k c`

But then Sandy immediately discards this formulation, and instead builds up a monoidal strawman, which is equivalent to the Maybe formulation, to knock down. To get some law that doesn't hold anyway?

https://reasonablypolymorphic.com/blog/api-analysis/

#Haskell

reasonablypolymorphic.com

Analyzing API Design via Algebraic Laws :: Reasonably Polymorphic

Is it just me, or is this a weird post by Sandy Maguire?

The Maybe formulation is incorrect -

`unionWith :: (Maybe a -> Maybe b -> c) -> Map k a -> Map k b -> Map k c`

And that the version with `These` is the right one to use -

`unionWith :: (These a b -> c) -> Map k a -> Map k b -> Map k c`

But then Sandy immediately discards this formulation, and instead builds up a monoidal strawman, which is equivalent to the Maybe formulation, to knock down. To get some law that doesn't hold anyway?

https://reasonablypolymorphic.com/blog/api-analysis/

#Haskell

reasonablypolymorphic.com

Analyzing API Design via Algebraic Laws :: Reasonably Polymorphic

@hackuador@functional.cafe

Brisbane Functional Programming Group THIS TUESDAY. Compiling parametric polymorphism (Isaac Elliott) + 2 years of the Security Response Team (Fraser Tweedale). See yas there, curious minds. lu.ma/yfkrxawh

lu.ma

BFPG Meetup - May 2025 - Compiling parametric polymorphism + Haskell Security Team · Luma

Join the BFPG Discord: https://discord.gg/yYz2d8w7FY Agenda 18:00: Welcome and setup Presentation #1: A "third way" of compiling parametric polymorphism -…

@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz

Compiling Haskell into Lean: A common abstract syntax for Haskell and interactive theorem provers. ~ Talitha Holcombe. digitalcommons.chapman.edu/eec

digitalcommons.chapman.edu

Compiling Haskell into Lean: A Common Abstract Syntax for Haskell and Interactive Theorem Provers

In this work, we introduce a program conversion tool, HS-TO-LEAN, that uses GHC's ghc-lib-parser API to translate Haskell programs into Lean code, which is then validated by the Lean compiler. The repo can be found at https://github.com/holcombet/hs-to-lean/tree/main. The result is a successful compilation of a fragment of Haskell into correct and executable Lean code that users can prove theorems about. We conducted a case study using a heap sort algorithm to support our claim that HS-TO-LEAN produces verifiable Lean code. Our approach is inspired by recent advances in formal verification of Haskell programs in Coq, and we currently restrict our attention to total Haskell. The compiler produces an AST that serves as a common level of abstraction between a fragment of Haskell and Lean. The abstract common fragment promotes translation between languages by simplifying and restructuring GHC's original AST, improving the readability and linearization of the AST. Future work on HS-TO-LEAN will extend the compiler to translate to other interactive theorem provers, including Coq, Agda, and Isabelle, making it portable and accessible to a range of verification efforts and communities. Future work also includes implementing bidirectionality, supporting the translation of Haskell code to a target proof assistant and vice versa. This method will expose an interesting level of abstraction that is applicable to all of the languages involved and produce a more maintainable compiler. These results contribute to the ongoing work in the formalization and verification of mathematics and programming and present a viable approach to unifying the formal systems of different proof assistants.

@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@kosmikus@functional.cafe
@kosmikus@functional.cafe
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz

Compiling Haskell into Lean: A common abstract syntax for Haskell and interactive theorem provers. ~ Talitha Holcombe. digitalcommons.chapman.edu/eec

digitalcommons.chapman.edu

Compiling Haskell into Lean: A Common Abstract Syntax for Haskell and Interactive Theorem Provers

In this work, we introduce a program conversion tool, HS-TO-LEAN, that uses GHC's ghc-lib-parser API to translate Haskell programs into Lean code, which is then validated by the Lean compiler. The repo can be found at https://github.com/holcombet/hs-to-lean/tree/main. The result is a successful compilation of a fragment of Haskell into correct and executable Lean code that users can prove theorems about. We conducted a case study using a heap sort algorithm to support our claim that HS-TO-LEAN produces verifiable Lean code. Our approach is inspired by recent advances in formal verification of Haskell programs in Coq, and we currently restrict our attention to total Haskell. The compiler produces an AST that serves as a common level of abstraction between a fragment of Haskell and Lean. The abstract common fragment promotes translation between languages by simplifying and restructuring GHC's original AST, improving the readability and linearization of the AST. Future work on HS-TO-LEAN will extend the compiler to translate to other interactive theorem provers, including Coq, Agda, and Isabelle, making it portable and accessible to a range of verification efforts and communities. Future work also includes implementing bidirectionality, supporting the translation of Haskell code to a target proof assistant and vice versa. This method will expose an interesting level of abstraction that is applicable to all of the languages involved and produce a more maintainable compiler. These results contribute to the ongoing work in the formalization and verification of mathematics and programming and present a viable approach to unifying the formal systems of different proof assistants.

@DiazCarrete@hachyderm.io

"Data.Graph.stronglyConnCompR" from "containers" distinguishes between isolated vertices and vertices with self-loops, which is the behavior I needed 👍
hackage-content.haskell.org/pa
hackage-content.haskell.org/pa

ghci> import Data.Graph
ghci> stronglyConnCompR [((),"foo",[])]
[AcyclicSCC ((),"foo",[])]
ghci> stronglyConnCompR [((),"foo",["foo"])]
[NECyclicSCC (((),"foo",["foo"]) :| [])]
ALT text

ghci> import Data.Graph ghci> stronglyConnCompR [((),"foo",[])] [AcyclicSCC ((),"foo",[])] ghci> stronglyConnCompR [((),"foo",["foo"])] [NECyclicSCC (((),"foo",["foo"]) :| [])]

@abnv@fantastic.earth

I've created a PR in , a simple setup framework, to add support for easy building of statically-linked executables (github.com/pwm/nixkell/pull/50). I'd appreciate it if any Nixkell users gives it a try for their projects. I've been using this code for a couple of my projects, and it works fine for me, but I'd like to have more working examples.

github.com

Add support for building statically-linked executable by abhin4v · Pull Request #50 · pwm/nixkell

This PR adds support for easily building statically-linked executable using Nixkell and Nix. Majorly, it: adds an overlays-static.nix file that configures GHC and Haskell packages for building sta...

@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@DiazCarrete@hachyderm.io
In a cross-compilation setting, the need for the stage distinction is even
clearer, because the runtime stage needs programs that run on the target architecture, whereas the compile-time stage expects programs to run on the host.
Cross-compilers may benefit from three or more stages (see section 5.7).
Levels and stages are often confused in literature but for clarity it is important
to distinguish between them [16]. Both may be represented as numbers, but levels
are offsets (differences relative to common reference point), whereas stages are
absolute values. Levels are a type-system concept as part of the specification of
valid programs, whereas stages are an implementation detail of the compiler.
ALT text

In a cross-compilation setting, the need for the stage distinction is even clearer, because the runtime stage needs programs that run on the target architecture, whereas the compile-time stage expects programs to run on the host. Cross-compilers may benefit from three or more stages (see section 5.7). Levels and stages are often confused in literature but for clarity it is important to distinguish between them [16]. Both may be represented as numbers, but levels are offsets (differences relative to common reference point), whereas stages are absolute values. Levels are a type-system concept as part of the specification of valid programs, whereas stages are an implementation detail of the compiler.

Ultimately, cross-stage persistence forces the build system to compile all modules and require all dependencies for all stages, even if the final program uses
only a small fragment of its dependency tree at any particular stage.
3 Implicit stage-persistence considered harmful
Implicit stage persistence seems convenient at first, but is the root of many
performance and cross-compilation issues in practice. If imported identifiers can
be arbitrarily used at any stage, the compiler must pessimistically assume they
will be used at all stages, and therefore it needs to compile all modules in a
project for both runtime and compile-time.
Our design allows implicit path-based cross-stage persistence to be disabled.
Identifiers must be used at precisely the level they are bound, and no other levels.
Instead, we should be able to explicitly control the level at which identifiers from
a module are imported. By being very precise about which levels modules are
needed at, there are many real-world advantages:
1. Currently, if a module enables TemplateHaskell, then all imported modules
are compiled to object code before name resolution takes place. This ensures
that any top level splices that may be encountered are able to be fully evaluated. This is a pessimisation because most of the imported identifiers, which
we have taken such pains to ensure we can run, will not actually be used in
a top-level splice.
ALT text

Ultimately, cross-stage persistence forces the build system to compile all modules and require all dependencies for all stages, even if the final program uses only a small fragment of its dependency tree at any particular stage. 3 Implicit stage-persistence considered harmful Implicit stage persistence seems convenient at first, but is the root of many performance and cross-compilation issues in practice. If imported identifiers can be arbitrarily used at any stage, the compiler must pessimistically assume they will be used at all stages, and therefore it needs to compile all modules in a project for both runtime and compile-time. Our design allows implicit path-based cross-stage persistence to be disabled. Identifiers must be used at precisely the level they are bound, and no other levels. Instead, we should be able to explicitly control the level at which identifiers from a module are imported. By being very precise about which levels modules are needed at, there are many real-world advantages: 1. Currently, if a module enables TemplateHaskell, then all imported modules are compiled to object code before name resolution takes place. This ensures that any top level splices that may be encountered are able to be fully evaluated. This is a pessimisation because most of the imported identifiers, which we have taken such pains to ensure we can run, will not actually be used in a top-level splice.

resolution depends on code generation for all dependencies. By distinguishing the small fraction of imported modules whose code is executed only at
compile time, we are able to improve this pessimisation.
2. GHC offers an -fno-code flag that instructs the compiler to parse and typecheck Haskell modules, but not to generate code, so as to offer quicker
feedback to the user. However, any modules imported by a module using
TemplateHaskell must be compiled to object code, despite the fact that
we will not generate object code for the module itself. By distinguishing
imported modules whose code is executed only at compile time, we can
eliminate or significantly reduce this unnecessary work.
3. IDEs such as Haskell Language Server face similar problems: they are interested only in the result of type-checking, but when TemplateHaskell is
enabled, many modules have to be unnecessarily compiled to bytecode.
4. Currently, when cross-compiling modules that use TemplateHaskell, all splices
are executed on the target even though compilation takes place on a separate host. This is a source of significant complexity. This work is a step
towards properly distinguishing dependencies that need to be compiled for
and executed on the host from those compiled for the target.
ALT text

resolution depends on code generation for all dependencies. By distinguishing the small fraction of imported modules whose code is executed only at compile time, we are able to improve this pessimisation. 2. GHC offers an -fno-code flag that instructs the compiler to parse and typecheck Haskell modules, but not to generate code, so as to offer quicker feedback to the user. However, any modules imported by a module using TemplateHaskell must be compiled to object code, despite the fact that we will not generate object code for the module itself. By distinguishing imported modules whose code is executed only at compile time, we can eliminate or significantly reduce this unnecessary work. 3. IDEs such as Haskell Language Server face similar problems: they are interested only in the result of type-checking, but when TemplateHaskell is enabled, many modules have to be unnecessarily compiled to bytecode. 4. Currently, when cross-compiling modules that use TemplateHaskell, all splices are executed on the target even though compilation takes place on a separate host. This is a source of significant complexity. This work is a step towards properly distinguishing dependencies that need to be compiled for and executed on the host from those compiled for the target.

In section 2.3 we said that modules were compiled for either the C or R stages.
Levelled imports make it possible to be precise about what stages we need dependencies.
– The main module is compiled for R. This is where the main function lives
and the entry-point to running the resulting executable.
– A normal import does not shift the stage at which the dependent module is
required.
– If a module M splice imports module A, then compiling M@R requires compiling module A@C.
– If a module M splice imports module A, then compiling M@C requires compiling module A@C.
– If a module N quote imports module B, then compiling N@C requires compiling module B at N@R.
– If a module N quote imports module B, then compiling N@R requires compiling module B at N@R
Stage arithmetic is saturating. Thus, when there are two stages, a quote
import corresponds to requiring the module at R, and a splice import to requiring
a module at C. When there are more than two stages then the imports can have
different meanings depending on the stage a module is compiled for. The compiler
can then choose appropriately how modules needed at C are compiled and how
modules needed at R are compiled. For example:
– In -fno-code mode, C modules may be compiled in dynamic way, but R
modules are not compiled at all.
– When using a profiled GHC. C modules must be compiled in profiled way
but R modules will be compiled in static way.
ALT text

In section 2.3 we said that modules were compiled for either the C or R stages. Levelled imports make it possible to be precise about what stages we need dependencies. – The main module is compiled for R. This is where the main function lives and the entry-point to running the resulting executable. – A normal import does not shift the stage at which the dependent module is required. – If a module M splice imports module A, then compiling M@R requires compiling module A@C. – If a module M splice imports module A, then compiling M@C requires compiling module A@C. – If a module N quote imports module B, then compiling N@C requires compiling module B at N@R. – If a module N quote imports module B, then compiling N@R requires compiling module B at N@R Stage arithmetic is saturating. Thus, when there are two stages, a quote import corresponds to requiring the module at R, and a splice import to requiring a module at C. When there are more than two stages then the imports can have different meanings depending on the stage a module is compiled for. The compiler can then choose appropriately how modules needed at C are compiled and how modules needed at R are compiled. For example: – In -fno-code mode, C modules may be compiled in dynamic way, but R modules are not compiled at all. – When using a profiled GHC. C modules must be compiled in profiled way but R modules will be compiled in static way.

@hackuador@functional.cafe

Brisbane Functional Programming Group May meetup Tue 2025-05-13. Compiling parametric polymorphism (Isaac Elliott) + 2 years of the Security Response Team (Fraser Tweedale). Be there or a be a lambda cube! lu.ma/yfkrxawh

lu.ma

BFPG Meetup - May 2025 - Compiling parametric polymorphism + Haskell Security Team · Luma

Join the BFPG Discord: https://discord.gg/yYz2d8w7FY Agenda 18:00: Welcome and setup Presentation #1: A "third way" of compiling parametric polymorphism -…

@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz

Magical Haskell: A friendly approach to modern functional programming, type theory, and artificial intelligence. ~ Anton Antich. books.google.com/books?id=aLBW

books.google.com

Magical Haskell

Discover a unique and fun approach to adopting modern typed functions programming patterns. This book uses playful metaphors and examples to help you learn Haskell through imagination, building on math without relying on imperative crutches or technical complexity. You’ll use math to build completely different Typed Functional patterns from the ground up and understand the link between building Mathematics through Types and constructing Haskell as a programming language. Intended for working with various applications, especially AI-powered apps, the book gently builds up to what are normally considered complex and difficult concepts all without needing a PhD to understand them. Illustrative explanations will guide you to tackle monads, using monad transformer stacks to structure real programs, foldable and traversable structures, as well as other Type classes. This book will also help you structure programs efficiently and apply your own abstractions to real-life problem domains. Next, you’ll explore exciting advancements in AI, including building with OpenAI APIs, creating a terminal chatbot, adding web functionality, and enhancing with retrieval-augmented generation. Finally, you’ll delve into AI multi-agents and future directions using Arrows abstraction, reinforcing Haskell’s design. Magical Haskell is a solution for programmers who feel limited by imperative programming languages but are also put off by excessively mathematical approaches. What You Will Learn Grasp a solid math foundation without complex technicalities for Types and Typeclasses. Solve problems via a typed functional approach and understand why it’s superior to what’s available in the imperative language world (“if it compiles, it runs”). Build your own abstractions to efficiently resolve problems in any given domain. Develop AI frameworks in Haskell, including chatbots, web functionality, and retrieval-augmented generation. Who This Book Is For Haskell programmers of all levels and those interested in Type Theory.

@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@DiazCarrete@hachyderm.io
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@zurihac@fosstodon.org

Greetings ZuriHackers!

Do you have a project you want to work on during ZuriHac? Now is a great time to get some contributors on board!

Do you not have a project yet? Then perhaps you want to have a look to get an idea about what others are working on!

Please find already registered projects at
zfoh.ch/zurihac2025/projects/ or submit a PR at github.com/zfoh/zfoh.ch/edit/m!

github.com

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

@zurihac@fosstodon.org

Greetings ZuriHackers!

Do you have a project you want to work on during ZuriHac? Now is a great time to get some contributors on board!

Do you not have a project yet? Then perhaps you want to have a look to get an idea about what others are working on!

Please find already registered projects at
zfoh.ch/zurihac2025/projects/ or submit a PR at github.com/zfoh/zfoh.ch/edit/m!

github.com

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

@harryprayiv@mastodon.social

If you’re a user or a proponent of please consider donating to the project to keep it alive.

It’s a fairly obscure project but, IMO, it is THE language for web .

On top of that, the backend was recently rewritten in which tends to be very popular choice in the world due to its rigor.

I see nipping at its heels but IMO, PS will always be a more bespoke and opinionated tool.

opencollective.com/purescript/

opencollective.com

Contribute - Open Collective

@harryprayiv@mastodon.social

If you’re a user or a proponent of please consider donating to the project to keep it alive.

It’s a fairly obscure project but, IMO, it is THE language for web .

On top of that, the backend was recently rewritten in which tends to be very popular choice in the world due to its rigor.

I see nipping at its heels but IMO, PS will always be a more bespoke and opinionated tool.

opencollective.com/purescript/

opencollective.com

Contribute - Open Collective

@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@bgamari@mastodon.social

GHC 9.10.2 release candidate 1 is now available for your testing. This is a big release for a minor release; far too many bug fixes to list. As always, please do open a ticket if you findanything amiss.

Happy Haskelling!

@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@kosmikus@functional.cafe
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@BoydStephenSmithJr@hachyderm.io

Whelp. Just got let go. They actually disabled my account while I was in the exit interview. Corporate IT is _cold_.

Anyway, I guess I'm looking for a new position maybe even be ?

I have to live in Cove, AR with my disabled family, so it will probably need to be 100% remote.

I'd prefer to keep doing or try out in production, or even something more exotic like or

@Jose_A_Alonso@mathstodon.xyz
@BoydStephenSmithJr@hachyderm.io

Whelp. Just got let go. They actually disabled my account while I was in the exit interview. Corporate IT is _cold_.

Anyway, I guess I'm looking for a new position maybe even be ?

I have to live in Cove, AR with my disabled family, so it will probably need to be 100% remote.

I'd prefer to keep doing or try out in production, or even something more exotic like or

@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@ipxfong@mastodon.sdf.org

Hey my Haskell curious friends. When I got started I picked up a copy of Learn You a Haskell. It's good but for someone who thought that functional programming meant breaking your c code into functions, it's a bit like sipping from the fire hose. I picked up a copy of Haskell: The Craft of Functional Programming. It's got a lot more background on how to think about Functional Programming. Paper copies are cheap but you can get a copy here for free: haskellcraft.com/craft3e/Home.

haskellcraft.com

Haskell: the Craft of Functional Programming

@Jose_A_Alonso@mathstodon.xyz
@ffaff@aleph.land
@ffaff@aleph.land
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz

Verified program extraction in number theory: The fundamental theorem of arithmetic and relatives. ~ Franziskus Wiesnet. arxiv.org/abs/2504.03460

arxiv.org

Verified Program Extraction in Number Theory: The Fundamental Theorem of Arithmetic and Relatives

This article revisits standard theorems from elementary number theory through a constructive, algorithmic, and proof-theoretic lens, within the theory of computable functionals. Key examples include Bèzout's identity, the fundamental theorem of arithmetic, and Fermat's factorization method. All definitions and theorems are fully formalized in the proof assistant Minlog, thereby laying the foundation for a comprehensive formal framework for number theory within Minlog. While formalization ensures correctness, our primary emphasis is on the computational content of proofs. Leveraging Minlog's built-in program extraction, we obtain executable terms that are exported as Haskell code. Efficiency of the extracted programs plays a central role. We show how performance considerations influence even the initial formulation of theorems and proofs. In particular, we compare formalizations based on binary encodings of natural numbers with those using the traditional unary (successor-based) representation. We present several core proofs in detail and reflect on the challenges that arise from formalization in contrast to informal reasoning. The complete formalisation is available online and linked for reference. Minlog's tactic scripts are designed to follow the structure of natural-language proofs, allowing each derivation step to be traced precisely and helping to bridge the gap between formal and classical mathematical reasoning.

@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz

Category theory using Haskell (An introduction with Moggi and Yoneda). ~ Shuichi Yukita. books.google.com/books?id=4Xc2

books.google.com

Category Theory Using Haskell

This unique book offers an introductory course on category theory, which became a working language in algebraic geometry and number theory in the 1950s and began to spread to logic and computer science soon after it was created. Offering excellent use of helpful examples in Haskell, the work covers (among other things) concepts of functors, natural transformations, monads, adjoints, universality, category equivalence, and many others. The main goal is to understand the Yoneda lemma, which can be used to reverse-engineer the implementation of a function. Later chapters offer more insights into computer science, including computation with output, nondeterministic computation, and continuation passing. Topics and features: Contains rigorous mathematical arguments to support the theory Provides numerous Haskell code-implementing examples Engages with plentiful diagram chasing, with special emphasis on the design patterns for constructing a large diagram out of basic small pieces Offers insights into category theory to quantum computing and the foundation of computing discipline Serves as a preparatory course for monoidal categories and higher categories The work will be useful to undergraduate students in computer science who have enough background in college mathematics such as linear algebra and basics in Haskell polymorphic functions. Further, it will appeal to graduate students and researchers in computing disciplines who want to newly acquire serious knowledge of category theory.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@DiazCarrete@hachyderm.io
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@kosmikus@functional.cafe
@ipxfong@mastodon.sdf.org

Took a little break from trying to wrap my head around functional programming to play with 10 PRINT on the C64.

A screenshot of my laptop showing a version of the classic 10 PRINT that I've changed slightly to pick a random set of characters.
ALT text

A screenshot of my laptop showing a version of the classic 10 PRINT that I've changed slightly to pick a random set of characters.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@dilawar@fosstodon.org

An underappreciated feature of is that Rust code found in the wild is very much likely to work and is of good quality. The crate doesn't have to be super mature!

My experience with code in the wild is much much better than JS or python code which is not suprising if you think about it. Programmers coding in
"hard" languages generally write better code? Perhaps same thing is with and ?

@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz

Learn Haskell by example. ~ Phillip Hagenlocher. books.google.com/books?id=n38p

books.google.com

Learn Haskell by Example

Learn Haskell by doing Haskell projects! In this book, you’ll get practical experience writing Haskell code and applying functional programming to actual development challenges.In Learn Haskell by Example, you’ll build your Haskell skills by working through hands-on challenges and conundrums. You’ll learn to look at each project through a Haskell lens, and then solve it using features like lazy evaluation, immutable data structures, and monads. In Learn Haskell by Example you will learn how to: • Use Haskell for daily programming tasks • Effectively apply functional concepts • Avoid common beginner pitfalls of Haskell • Apply abstract concepts in the Haskell language • Debug and profile Haskell applications • Improve the performance of Haskell applications Haskell is an amazing choice for applications that need an extra guarantee of safety, such as in smart contracts, data intensive applications, and large scale distributed systems. In this book, you’ll see just how practical Haskell can be for creating programs by building your own engaging projects! Learn how to structure real-world applications, how to work with the Haskell tool chain effectively, and what to look out for when writing critical sections in the program's logic. Best of all, each project in this book is fully extensible and customizable so you can keep tinkering with your favorites! About the technology Programmers spend a lot of time debugging and refactoring code, reading comments and documentation, and trying to make sense out of complex designs. Haskell, a powerful, beautiful, and challenging functional programming language, promises a different path. By focusing your attention on simple functions, clearly-defined behaviors, and the right high-level abstractions, Haskell disallows the dangerous behaviors that usually lead to bugs and crashes. About the book Learn Haskell by Example teaches you to build applications in Haskell by designing and coding fun and engaging projects. In this easy-to-follow guide, you’ll create a domain specific language for music, an image processing library, and more! You’ll learn Haskell from the ground-up with a focus on important concepts like function design, composition, and data immutability. Each project gives you a new insight into how to think in Haskell and helps you understand why many Haskell developers say they will never use another language again. What's inside • Use Haskell for daily programming tasks • Purely functional programming • Avoid common Haskell pitfalls About the reader For readers who know how to program in an object-oriented language. About the author Philipp Hagenlocher is a full time Haskell developer, and the creator of the beloved Haskell for Imperative Programmers YouTube course. The technical editor on this book was Alexander Vershilov. Table of Contents 1 Introduction 2 Ancient secret keeping on modern machines 3 Every line counts 4 Line numbering tool 5 Words and graphs 6 Solving the ladder game 7 Working with CSV files 8 A tool for CSV 9 Quick checks and random tests 10 Digital music box 11 Programming musical compositions 12 Parsing pixel data 13 Parallel image processing 14 Files and exceptions 15 Transformers for synchronizing 16 JSON and SQL 17 APIs using Servant Appendix A The Haskell Toolchain Appendix B Lazy evaluation

@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@GerryT@mastodon.social
@GerryT@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@h4ckernews@mastodon.social
@h4ckernews@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@kosmikus@functional.cafe

Tomorrow, 2025-03-12, at 1930 UTC (note: one hour later than usual in Canada / US due to asynchronous DST shifts), there'll be a new episode of the , titled "understanding through a model". We'll talk about QuickCheck and convolutions ...

youtube.com/watch?v=0QTt2W7CVn

youtube.com

The Haskell Unfolder Episode 40: understanding through a model

QuickCheck is useful for more than just testing. Comparing the behaviour of a system to a model can be used to check if a system under construction is worki...

@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@hongminhee@hollo.social

Just what the internet needed: another attempt to explain ! 🙄 But this time I'm comparing and approaches to show why make all the difference. Turns out those JavaScript Promise analogies only tell half the story…

https://hackers.pub/@hongminhee/2025/monads

hackers.pub

Monads: Beyond Simple Analogies—Reflections on Functional Programming Paradigms

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool. The Elegant Power of Monads in Haskell It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem. The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated: You can write code once that works across many contexts (Maybe, [], IO, State, etc.) Generic functions like sequence, mapM, and others become available across all monadic types The same patterns and mental models apply consistently across different computational contexts For example, a simple conditional function like this works beautifully in any monadic context: whenM :: Monad m => m Bool -> m () -> m () whenM condition action = do result <- condition if result then action else return () Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse. OCaml's Different Approach Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design: Structural Differences OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient: (* OCaml monad implementation requires more boilerplate *) module type MONAD = sig type 'a t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end module OptionMonad : MONAD with type 'a t = 'a option = struct type 'a t = 'a option let return x = Some x let bind m f = match m with | None -> None | Some x -> f x end OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive: -- Haskell's elegant do notation userInfo = do name <- getLine age <- readLn return (name, age) Compared to the more verbose OCaml equivalent: let user_info = get_line >>= fun name -> read_ln >>= fun age -> return (name, age) The readability difference becomes even more pronounced in more complex monadic operations. Philosophical Differences Beyond syntax, the languages differ in their fundamental approach to effects: Haskell is purely functional, making monads essential for managing effects in a principled way OCaml permits direct side effects, often making monadic abstractions optional This allows OCaml programmers to write more direct code when appropriate: (* Direct style in OCaml *) let get_user_info () = print_string "Name: "; let name = read_line () in print_string "Age: "; let age = int_of_string (read_line ()) in (name, age) OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring: Direct use of option and result types Module-level abstractions through functors Continuation-passing style when needed While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides. Reflections on Language Design These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system. Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts. OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount. After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience. What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

@hongminhee@hackers.pub

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool.

The Elegant Power of Monads in Haskell

It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem.

The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated:

  • You can write code once that works across many contexts (Maybe, [], IO, State, etc.)
  • Generic functions like sequence, mapM, and others become available across all monadic types
  • The same patterns and mental models apply consistently across different computational contexts

For example, a simple conditional function like this works beautifully in any monadic context:

whenM :: Monad m => m Bool -> m () -> m ()
whenM condition action = do
  result <- condition
  if result then action else return ()

Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse.

OCaml's Different Approach

Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design:

Structural Differences

OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient:

(* OCaml monad implementation requires more boilerplate *)
module type MONAD = sig
  type 'a t
  val return : 'a -> 'a t
  val bind : 'a t -> ('a -> 'b t) -> 'b t
end

module OptionMonad : MONAD with type 'a t = 'a option = struct
  type 'a t = 'a option
  let return x = Some x
  let bind m f = match m with
    | None -> None
    | Some x -> f x
end

OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive:

-- Haskell's elegant do notation
userInfo = do
  name <- getLine
  age <- readLn
  return (name, age)

Compared to the more verbose OCaml equivalent:

let user_info =
  get_line >>= fun name ->
  read_ln >>= fun age ->
  return (name, age)

The readability difference becomes even more pronounced in more complex monadic operations.

Philosophical Differences

Beyond syntax, the languages differ in their fundamental approach to effects:

  • Haskell is purely functional, making monads essential for managing effects in a principled way
  • OCaml permits direct side effects, often making monadic abstractions optional

This allows OCaml programmers to write more direct code when appropriate:

(* Direct style in OCaml *)
let get_user_info () =
  print_string "Name: ";
  let name = read_line () in
  print_string "Age: ";
  let age = int_of_string (read_line ()) in
  (name, age)

OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring:

  • Direct use of option and result types
  • Module-level abstractions through functors
  • Continuation-passing style when needed

While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides.

Reflections on Language Design

These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system.

Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts.

OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount.

After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience.

What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

@hongminhee@hollo.social

Just what the internet needed: another attempt to explain ! 🙄 But this time I'm comparing and approaches to show why make all the difference. Turns out those JavaScript Promise analogies only tell half the story…

https://hackers.pub/@hongminhee/2025/monads

hackers.pub

Monads: Beyond Simple Analogies—Reflections on Functional Programming Paradigms

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool. The Elegant Power of Monads in Haskell It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem. The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated: You can write code once that works across many contexts (Maybe, [], IO, State, etc.) Generic functions like sequence, mapM, and others become available across all monadic types The same patterns and mental models apply consistently across different computational contexts For example, a simple conditional function like this works beautifully in any monadic context: whenM :: Monad m => m Bool -> m () -> m () whenM condition action = do result <- condition if result then action else return () Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse. OCaml's Different Approach Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design: Structural Differences OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient: (* OCaml monad implementation requires more boilerplate *) module type MONAD = sig type 'a t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end module OptionMonad : MONAD with type 'a t = 'a option = struct type 'a t = 'a option let return x = Some x let bind m f = match m with | None -> None | Some x -> f x end OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive: -- Haskell's elegant do notation userInfo = do name <- getLine age <- readLn return (name, age) Compared to the more verbose OCaml equivalent: let user_info = get_line >>= fun name -> read_ln >>= fun age -> return (name, age) The readability difference becomes even more pronounced in more complex monadic operations. Philosophical Differences Beyond syntax, the languages differ in their fundamental approach to effects: Haskell is purely functional, making monads essential for managing effects in a principled way OCaml permits direct side effects, often making monadic abstractions optional This allows OCaml programmers to write more direct code when appropriate: (* Direct style in OCaml *) let get_user_info () = print_string "Name: "; let name = read_line () in print_string "Age: "; let age = int_of_string (read_line ()) in (name, age) OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring: Direct use of option and result types Module-level abstractions through functors Continuation-passing style when needed While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides. Reflections on Language Design These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system. Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts. OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount. After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience. What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

@hongminhee@hackers.pub

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool.

The Elegant Power of Monads in Haskell

It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem.

The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated:

  • You can write code once that works across many contexts (Maybe, [], IO, State, etc.)
  • Generic functions like sequence, mapM, and others become available across all monadic types
  • The same patterns and mental models apply consistently across different computational contexts

For example, a simple conditional function like this works beautifully in any monadic context:

whenM :: Monad m => m Bool -> m () -> m ()
whenM condition action = do
  result <- condition
  if result then action else return ()

Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse.

OCaml's Different Approach

Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design:

Structural Differences

OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient:

(* OCaml monad implementation requires more boilerplate *)
module type MONAD = sig
  type 'a t
  val return : 'a -> 'a t
  val bind : 'a t -> ('a -> 'b t) -> 'b t
end

module OptionMonad : MONAD with type 'a t = 'a option = struct
  type 'a t = 'a option
  let return x = Some x
  let bind m f = match m with
    | None -> None
    | Some x -> f x
end

OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive:

-- Haskell's elegant do notation
userInfo = do
  name <- getLine
  age <- readLn
  return (name, age)

Compared to the more verbose OCaml equivalent:

let user_info =
  get_line >>= fun name ->
  read_ln >>= fun age ->
  return (name, age)

The readability difference becomes even more pronounced in more complex monadic operations.

Philosophical Differences

Beyond syntax, the languages differ in their fundamental approach to effects:

  • Haskell is purely functional, making monads essential for managing effects in a principled way
  • OCaml permits direct side effects, often making monadic abstractions optional

This allows OCaml programmers to write more direct code when appropriate:

(* Direct style in OCaml *)
let get_user_info () =
  print_string "Name: ";
  let name = read_line () in
  print_string "Age: ";
  let age = int_of_string (read_line ()) in
  (name, age)

OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring:

  • Direct use of option and result types
  • Module-level abstractions through functors
  • Continuation-passing style when needed

While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides.

Reflections on Language Design

These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system.

Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts.

OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount.

After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience.

What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

またまた世界にモナドの解説が増えてしまいました。😅 今回はHaskellとOCamlのアプローチを比較して、型クラスがどれだけ重要な違いを齎すかに就いて書いてみました。JavaScriptのPromiseと比べる譬えは半分しか真実を語っていないんですよね…

https://hackers.pub/@hongminhee/2025/monads

hackers.pub

Monads: Beyond Simple Analogies—Reflections on Functional Programming Paradigms

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool. The Elegant Power of Monads in Haskell It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem. The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated: You can write code once that works across many contexts (Maybe, [], IO, State, etc.) Generic functions like sequence, mapM, and others become available across all monadic types The same patterns and mental models apply consistently across different computational contexts For example, a simple conditional function like this works beautifully in any monadic context: whenM :: Monad m => m Bool -> m () -> m () whenM condition action = do result <- condition if result then action else return () Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse. OCaml's Different Approach Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design: Structural Differences OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient: (* OCaml monad implementation requires more boilerplate *) module type MONAD = sig type 'a t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end module OptionMonad : MONAD with type 'a t = 'a option = struct type 'a t = 'a option let return x = Some x let bind m f = match m with | None -> None | Some x -> f x end OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive: -- Haskell's elegant do notation userInfo = do name <- getLine age <- readLn return (name, age) Compared to the more verbose OCaml equivalent: let user_info = get_line >>= fun name -> read_ln >>= fun age -> return (name, age) The readability difference becomes even more pronounced in more complex monadic operations. Philosophical Differences Beyond syntax, the languages differ in their fundamental approach to effects: Haskell is purely functional, making monads essential for managing effects in a principled way OCaml permits direct side effects, often making monadic abstractions optional This allows OCaml programmers to write more direct code when appropriate: (* Direct style in OCaml *) let get_user_info () = print_string "Name: "; let name = read_line () in print_string "Age: "; let age = int_of_string (read_line ()) in (name, age) OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring: Direct use of option and result types Module-level abstractions through functors Continuation-passing style when needed While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides. Reflections on Language Design These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system. Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts. OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount. After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience. What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

@hongminhee@hackers.pub

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool.

The Elegant Power of Monads in Haskell

It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem.

The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated:

  • You can write code once that works across many contexts (Maybe, [], IO, State, etc.)
  • Generic functions like sequence, mapM, and others become available across all monadic types
  • The same patterns and mental models apply consistently across different computational contexts

For example, a simple conditional function like this works beautifully in any monadic context:

whenM :: Monad m => m Bool -> m () -> m ()
whenM condition action = do
  result <- condition
  if result then action else return ()

Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse.

OCaml's Different Approach

Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design:

Structural Differences

OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient:

(* OCaml monad implementation requires more boilerplate *)
module type MONAD = sig
  type 'a t
  val return : 'a -> 'a t
  val bind : 'a t -> ('a -> 'b t) -> 'b t
end

module OptionMonad : MONAD with type 'a t = 'a option = struct
  type 'a t = 'a option
  let return x = Some x
  let bind m f = match m with
    | None -> None
    | Some x -> f x
end

OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive:

-- Haskell's elegant do notation
userInfo = do
  name <- getLine
  age <- readLn
  return (name, age)

Compared to the more verbose OCaml equivalent:

let user_info =
  get_line >>= fun name ->
  read_ln >>= fun age ->
  return (name, age)

The readability difference becomes even more pronounced in more complex monadic operations.

Philosophical Differences

Beyond syntax, the languages differ in their fundamental approach to effects:

  • Haskell is purely functional, making monads essential for managing effects in a principled way
  • OCaml permits direct side effects, often making monadic abstractions optional

This allows OCaml programmers to write more direct code when appropriate:

(* Direct style in OCaml *)
let get_user_info () =
  print_string "Name: ";
  let name = read_line () in
  print_string "Age: ";
  let age = int_of_string (read_line ()) in
  (name, age)

OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring:

  • Direct use of option and result types
  • Module-level abstractions through functors
  • Continuation-passing style when needed

While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides.

Reflections on Language Design

These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system.

Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts.

OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount.

After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience.

What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

またまた世界にモナドの解説が増えてしまいました。😅 今回はHaskellとOCamlのアプローチを比較して、型クラスがどれだけ重要な違いを齎すかに就いて書いてみました。JavaScriptのPromiseと比べる譬えは半分しか真実を語っていないんですよね…

https://hackers.pub/@hongminhee/2025/monads

hackers.pub

Monads: Beyond Simple Analogies—Reflections on Functional Programming Paradigms

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool. The Elegant Power of Monads in Haskell It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem. The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated: You can write code once that works across many contexts (Maybe, [], IO, State, etc.) Generic functions like sequence, mapM, and others become available across all monadic types The same patterns and mental models apply consistently across different computational contexts For example, a simple conditional function like this works beautifully in any monadic context: whenM :: Monad m => m Bool -> m () -> m () whenM condition action = do result <- condition if result then action else return () Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse. OCaml's Different Approach Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design: Structural Differences OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient: (* OCaml monad implementation requires more boilerplate *) module type MONAD = sig type 'a t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end module OptionMonad : MONAD with type 'a t = 'a option = struct type 'a t = 'a option let return x = Some x let bind m f = match m with | None -> None | Some x -> f x end OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive: -- Haskell's elegant do notation userInfo = do name <- getLine age <- readLn return (name, age) Compared to the more verbose OCaml equivalent: let user_info = get_line >>= fun name -> read_ln >>= fun age -> return (name, age) The readability difference becomes even more pronounced in more complex monadic operations. Philosophical Differences Beyond syntax, the languages differ in their fundamental approach to effects: Haskell is purely functional, making monads essential for managing effects in a principled way OCaml permits direct side effects, often making monadic abstractions optional This allows OCaml programmers to write more direct code when appropriate: (* Direct style in OCaml *) let get_user_info () = print_string "Name: "; let name = read_line () in print_string "Age: "; let age = int_of_string (read_line ()) in (name, age) OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring: Direct use of option and result types Module-level abstractions through functors Continuation-passing style when needed While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides. Reflections on Language Design These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system. Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts. OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount. After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience. What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

@hongminhee@hackers.pub

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool.

The Elegant Power of Monads in Haskell

It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem.

The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated:

  • You can write code once that works across many contexts (Maybe, [], IO, State, etc.)
  • Generic functions like sequence, mapM, and others become available across all monadic types
  • The same patterns and mental models apply consistently across different computational contexts

For example, a simple conditional function like this works beautifully in any monadic context:

whenM :: Monad m => m Bool -> m () -> m ()
whenM condition action = do
  result <- condition
  if result then action else return ()

Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse.

OCaml's Different Approach

Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design:

Structural Differences

OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient:

(* OCaml monad implementation requires more boilerplate *)
module type MONAD = sig
  type 'a t
  val return : 'a -> 'a t
  val bind : 'a t -> ('a -> 'b t) -> 'b t
end

module OptionMonad : MONAD with type 'a t = 'a option = struct
  type 'a t = 'a option
  let return x = Some x
  let bind m f = match m with
    | None -> None
    | Some x -> f x
end

OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive:

-- Haskell's elegant do notation
userInfo = do
  name <- getLine
  age <- readLn
  return (name, age)

Compared to the more verbose OCaml equivalent:

let user_info =
  get_line >>= fun name ->
  read_ln >>= fun age ->
  return (name, age)

The readability difference becomes even more pronounced in more complex monadic operations.

Philosophical Differences

Beyond syntax, the languages differ in their fundamental approach to effects:

  • Haskell is purely functional, making monads essential for managing effects in a principled way
  • OCaml permits direct side effects, often making monadic abstractions optional

This allows OCaml programmers to write more direct code when appropriate:

(* Direct style in OCaml *)
let get_user_info () =
  print_string "Name: ";
  let name = read_line () in
  print_string "Age: ";
  let age = int_of_string (read_line ()) in
  (name, age)

OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring:

  • Direct use of option and result types
  • Module-level abstractions through functors
  • Continuation-passing style when needed

While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides.

Reflections on Language Design

These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system.

Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts.

OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount.

After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience.

What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

@hongminhee@hollo.social

Just what the internet needed: another attempt to explain ! 🙄 But this time I'm comparing and approaches to show why make all the difference. Turns out those JavaScript Promise analogies only tell half the story…

https://hackers.pub/@hongminhee/2025/monads

hackers.pub

Monads: Beyond Simple Analogies—Reflections on Functional Programming Paradigms

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool. The Elegant Power of Monads in Haskell It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem. The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated: You can write code once that works across many contexts (Maybe, [], IO, State, etc.) Generic functions like sequence, mapM, and others become available across all monadic types The same patterns and mental models apply consistently across different computational contexts For example, a simple conditional function like this works beautifully in any monadic context: whenM :: Monad m => m Bool -> m () -> m () whenM condition action = do result <- condition if result then action else return () Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse. OCaml's Different Approach Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design: Structural Differences OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient: (* OCaml monad implementation requires more boilerplate *) module type MONAD = sig type 'a t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end module OptionMonad : MONAD with type 'a t = 'a option = struct type 'a t = 'a option let return x = Some x let bind m f = match m with | None -> None | Some x -> f x end OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive: -- Haskell's elegant do notation userInfo = do name <- getLine age <- readLn return (name, age) Compared to the more verbose OCaml equivalent: let user_info = get_line >>= fun name -> read_ln >>= fun age -> return (name, age) The readability difference becomes even more pronounced in more complex monadic operations. Philosophical Differences Beyond syntax, the languages differ in their fundamental approach to effects: Haskell is purely functional, making monads essential for managing effects in a principled way OCaml permits direct side effects, often making monadic abstractions optional This allows OCaml programmers to write more direct code when appropriate: (* Direct style in OCaml *) let get_user_info () = print_string "Name: "; let name = read_line () in print_string "Age: "; let age = int_of_string (read_line ()) in (name, age) OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring: Direct use of option and result types Module-level abstractions through functors Continuation-passing style when needed While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides. Reflections on Language Design These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system. Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts. OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount. After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience. What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

@hongminhee@hackers.pub

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool.

The Elegant Power of Monads in Haskell

It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem.

The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated:

  • You can write code once that works across many contexts (Maybe, [], IO, State, etc.)
  • Generic functions like sequence, mapM, and others become available across all monadic types
  • The same patterns and mental models apply consistently across different computational contexts

For example, a simple conditional function like this works beautifully in any monadic context:

whenM :: Monad m => m Bool -> m () -> m ()
whenM condition action = do
  result <- condition
  if result then action else return ()

Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse.

OCaml's Different Approach

Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design:

Structural Differences

OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient:

(* OCaml monad implementation requires more boilerplate *)
module type MONAD = sig
  type 'a t
  val return : 'a -> 'a t
  val bind : 'a t -> ('a -> 'b t) -> 'b t
end

module OptionMonad : MONAD with type 'a t = 'a option = struct
  type 'a t = 'a option
  let return x = Some x
  let bind m f = match m with
    | None -> None
    | Some x -> f x
end

OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive:

-- Haskell's elegant do notation
userInfo = do
  name <- getLine
  age <- readLn
  return (name, age)

Compared to the more verbose OCaml equivalent:

let user_info =
  get_line >>= fun name ->
  read_ln >>= fun age ->
  return (name, age)

The readability difference becomes even more pronounced in more complex monadic operations.

Philosophical Differences

Beyond syntax, the languages differ in their fundamental approach to effects:

  • Haskell is purely functional, making monads essential for managing effects in a principled way
  • OCaml permits direct side effects, often making monadic abstractions optional

This allows OCaml programmers to write more direct code when appropriate:

(* Direct style in OCaml *)
let get_user_info () =
  print_string "Name: ";
  let name = read_line () in
  print_string "Age: ";
  let age = int_of_string (read_line ()) in
  (name, age)

OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring:

  • Direct use of option and result types
  • Module-level abstractions through functors
  • Continuation-passing style when needed

While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides.

Reflections on Language Design

These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system.

Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts.

OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount.

After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience.

What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

@Jose_A_Alonso@mathstodon.xyz
@simonmic@fosstodon.org

hledger 1.42 is out, with new run and repl commands.
Thank you to contributors Dmitry Astapov, gesh, Thomas
Miedema, Joschua Kesper, and Lars Kellogg-Stedman !

- github.com/simonmichael/hledge
- hledger.org/relnotes.html#2025
- hledger.org/install

is free, robust, friendly, multicurrency, double-entry,
software for unix, mac, windows, and the web,
written in for reliability.

hledger.org

Install - hledger

plain text accounting, made easy

@DiazCarrete@hachyderm.io
@Profpatsch@mastodon.xyz

Let’s goooooo

Since GHC 9.6, any non-empty double quoted string can be used as a label. The restriction that the label must be a valid identifier has also been lifted.

Examples of newly allowed syntax:

    Leading capital letters: #Foo equivalant to getLabel @”Foo”

    Numeric characters: #3.14 equivalent to getLabel @”3.14”

    Arbitrary strings: #”Hello, World!” equivalent to getLabel @”Hello, World!”

Here is an example of the more permissive use of this extension, available since GHC 9.6:
ALT text

Since GHC 9.6, any non-empty double quoted string can be used as a label. The restriction that the label must be a valid identifier has also been lifted. Examples of newly allowed syntax: Leading capital letters: #Foo equivalant to getLabel @”Foo” Numeric characters: #3.14 equivalent to getLabel @”3.14” Arbitrary strings: #”Hello, World!” equivalent to getLabel @”Hello, World!” Here is an example of the more permissive use of this extension, available since GHC 9.6:


-- case-match on an e2 with a t2 that provides the relevant functions
caseE2 ::
  forall l1 t1 l2 t2 matcher r.
  ( HasField l1 matcher (t1 -> r),
    HasField l2 matcher (t2 -> r)
  ) =>
  matcher ->
  E2 l1 t1 l2 t2 ->
  r
{-# INLINE caseE2 #-}
caseE2 m e2 = do
  let f1 = getField @l1 m
  let f2 = getField @l2 m
  case e2 of
    E21 a -> f1 $ getField @l1 a
    E22 b -> f2 $ getField @l2 b

t2 :: forall l1 t1 l2 t2. LabelPrx l1 -> t1 -> LabelPrx l2 -> t2 -> T2 l1 t1 l2 t2
{-# INLINE t2 #-}
t2 LabelPrx a LabelPrx b = T2 (label @l1 a) (label @l2 b)

data LabelPrx (l :: Symbol) = LabelPrx

instance (l ~ l') => IsLabel l (LabelPrx l') where
  fromLabel = LabelPrx

instance (t ~ t') => IsLabel l (t -> (Label l t')) where
  fromLabel = label @l
ALT text

-- case-match on an e2 with a t2 that provides the relevant functions caseE2 :: forall l1 t1 l2 t2 matcher r. ( HasField l1 matcher (t1 -> r), HasField l2 matcher (t2 -> r) ) => matcher -> E2 l1 t1 l2 t2 -> r {-# INLINE caseE2 #-} caseE2 m e2 = do let f1 = getField @l1 m let f2 = getField @l2 m case e2 of E21 a -> f1 $ getField @l1 a E22 b -> f2 $ getField @l2 b t2 :: forall l1 t1 l2 t2. LabelPrx l1 -> t1 -> LabelPrx l2 -> t2 -> T2 l1 t1 l2 t2 {-# INLINE t2 #-} t2 LabelPrx a LabelPrx b = T2 (label @l1 a) (label @l2 b) data LabelPrx (l :: Symbol) = LabelPrx instance (l ~ l') => IsLabel l (LabelPrx l') where fromLabel = LabelPrx instance (t ~ t') => IsLabel l (t -> (Label l t')) where fromLabel = label @l

matcher :: T2 "oh yeah" (Int -> String) "mylabel" (a -> a)
matcher = t2 #"oh yeah" (\(i :: Int) -> show $ i + 1) #mylabel id

bar :: E2 "oh yeah" Int "mylabel" String
bar = E21 (#"oh yeah" 42)

baz :: String
baz = bar & caseE2 matcher
ALT text

matcher :: T2 "oh yeah" (Int -> String) "mylabel" (a -> a) matcher = t2 #"oh yeah" (\(i :: Int) -> show $ i + 1) #mylabel id bar :: E2 "oh yeah" Int "mylabel" String bar = E21 (#"oh yeah" 42) baz :: String baz = bar & caseE2 matcher

@Profpatsch@mastodon.xyz

Let’s goooooo

Since GHC 9.6, any non-empty double quoted string can be used as a label. The restriction that the label must be a valid identifier has also been lifted.

Examples of newly allowed syntax:

    Leading capital letters: #Foo equivalant to getLabel @”Foo”

    Numeric characters: #3.14 equivalent to getLabel @”3.14”

    Arbitrary strings: #”Hello, World!” equivalent to getLabel @”Hello, World!”

Here is an example of the more permissive use of this extension, available since GHC 9.6:
ALT text

Since GHC 9.6, any non-empty double quoted string can be used as a label. The restriction that the label must be a valid identifier has also been lifted. Examples of newly allowed syntax: Leading capital letters: #Foo equivalant to getLabel @”Foo” Numeric characters: #3.14 equivalent to getLabel @”3.14” Arbitrary strings: #”Hello, World!” equivalent to getLabel @”Hello, World!” Here is an example of the more permissive use of this extension, available since GHC 9.6:


-- case-match on an e2 with a t2 that provides the relevant functions
caseE2 ::
  forall l1 t1 l2 t2 matcher r.
  ( HasField l1 matcher (t1 -> r),
    HasField l2 matcher (t2 -> r)
  ) =>
  matcher ->
  E2 l1 t1 l2 t2 ->
  r
{-# INLINE caseE2 #-}
caseE2 m e2 = do
  let f1 = getField @l1 m
  let f2 = getField @l2 m
  case e2 of
    E21 a -> f1 $ getField @l1 a
    E22 b -> f2 $ getField @l2 b

t2 :: forall l1 t1 l2 t2. LabelPrx l1 -> t1 -> LabelPrx l2 -> t2 -> T2 l1 t1 l2 t2
{-# INLINE t2 #-}
t2 LabelPrx a LabelPrx b = T2 (label @l1 a) (label @l2 b)

data LabelPrx (l :: Symbol) = LabelPrx

instance (l ~ l') => IsLabel l (LabelPrx l') where
  fromLabel = LabelPrx

instance (t ~ t') => IsLabel l (t -> (Label l t')) where
  fromLabel = label @l
ALT text

-- case-match on an e2 with a t2 that provides the relevant functions caseE2 :: forall l1 t1 l2 t2 matcher r. ( HasField l1 matcher (t1 -> r), HasField l2 matcher (t2 -> r) ) => matcher -> E2 l1 t1 l2 t2 -> r {-# INLINE caseE2 #-} caseE2 m e2 = do let f1 = getField @l1 m let f2 = getField @l2 m case e2 of E21 a -> f1 $ getField @l1 a E22 b -> f2 $ getField @l2 b t2 :: forall l1 t1 l2 t2. LabelPrx l1 -> t1 -> LabelPrx l2 -> t2 -> T2 l1 t1 l2 t2 {-# INLINE t2 #-} t2 LabelPrx a LabelPrx b = T2 (label @l1 a) (label @l2 b) data LabelPrx (l :: Symbol) = LabelPrx instance (l ~ l') => IsLabel l (LabelPrx l') where fromLabel = LabelPrx instance (t ~ t') => IsLabel l (t -> (Label l t')) where fromLabel = label @l

matcher :: T2 "oh yeah" (Int -> String) "mylabel" (a -> a)
matcher = t2 #"oh yeah" (\(i :: Int) -> show $ i + 1) #mylabel id

bar :: E2 "oh yeah" Int "mylabel" String
bar = E21 (#"oh yeah" 42)

baz :: String
baz = bar & caseE2 matcher
ALT text

matcher :: T2 "oh yeah" (Int -> String) "mylabel" (a -> a) matcher = t2 #"oh yeah" (\(i :: Int) -> show $ i + 1) #mylabel id bar :: E2 "oh yeah" Int "mylabel" String bar = E21 (#"oh yeah" 42) baz :: String baz = bar & caseE2 matcher

@simonmic@fosstodon.org

hledger 1.42 is out, with new run and repl commands.
Thank you to contributors Dmitry Astapov, gesh, Thomas
Miedema, Joschua Kesper, and Lars Kellogg-Stedman !

- github.com/simonmichael/hledge
- hledger.org/relnotes.html#2025
- hledger.org/install

is free, robust, friendly, multicurrency, double-entry,
software for unix, mac, windows, and the web,
written in for reliability.

hledger.org

Install - hledger

plain text accounting, made easy

@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@cdavies@mastodon.scot

I really need to master functions and functional programming generally. There's something about them that addles my brain. It's bothering me that I'm not good at them.
I can read through other people's functions and mostly work out what they do, but I struggle with writing my own.

I've read blogs that suggest learning or as they are pure functional languages, and it helps solidify the logic.

@Jose_A_Alonso@mathstodon.xyz
@Jose_A_Alonso@mathstodon.xyz
@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@kack@mastodon.social

Trying to figure out what to use in my next personal project. Trying to stay away from touching JS. I have been considering becuase I like . I also have been considering and becuase I love . I guess I could choose any backend but I am really looking for a frontend replacement to make a QOL improvement

@kosmikus@functional.cafe
@Jose_A_Alonso@mathstodon.xyz

Update n°42 from the GHC team at IOG

engineering.iog.io/2025-02-20-

Highlights:
• Sylvain worked on making GHC built with cabal-install pass the testsuite

• Luite looked into using cosmopolitan libc to see if we can make a GHC cross compiler that produces multi-arch/os binaries

engineering.iog.io

IOG GHC Update #42 | IOG Engineering

Triweekly update from the GHC DevX team at IOG.

@haskell_discussions@mastodon.social
@abnv@fantastic.earth

In an alternative timeline where is the norm instead of Object-oriented programming, and is the most popular instead of , there is a list of tutorials trying to explain what Objects are to programmers in terms of FP concepts, the most popular of which is, “Objects are Comonads”.

However, we don't live in that timeline, so we'll have to be content with the inverse article, “Comonads are Objects” haskellforall.com/2013/02/you- .

haskellforall.com

Comonads are objects

Haskell programmers popularized the use of monads to structure imperative computations, complete with syntactic sugar in the form of do not...

@abnv@fantastic.earth

In an alternative timeline where is the norm instead of Object-oriented programming, and is the most popular instead of , there is a list of tutorials trying to explain what Objects are to programmers in terms of FP concepts, the most popular of which is, “Objects are Comonads”.

However, we don't live in that timeline, so we'll have to be content with the inverse article, “Comonads are Objects” haskellforall.com/2013/02/you- .

haskellforall.com

Comonads are objects

Haskell programmers popularized the use of monads to structure imperative computations, complete with syntactic sugar in the form of do not...

@abnv@fantastic.earth

Comparing the chart of tutorials by year[1] with the Gartner hype cycle graph, it seems like we are almost at the Peak of Inflated Expectations phase now.

[1]: From the list of Monad tutorials (wiki.haskell.org/Monad_tutoria).

In my lifetime, I hope to see the Slope of Enlightenment phase when people stop asking what a Monad is, and the further Plateau of Productivity phase when everyone knows what it is.

A line chart showing number of Monad tutorials published yearly from 1990 to 2023. The number grows slowly at the beginning, then rises sharply starting 2015, then seems to plateau around 2022.
ALT text

A line chart showing number of Monad tutorials published yearly from 1990 to 2023. The number grows slowly at the beginning, then rises sharply starting 2015, then seems to plateau around 2022.

The graph of the Gartner Hype Cycle.
ALT text

The graph of the Gartner Hype Cycle.

@haskell_discussions@mastodon.social
@haskell_discussions@mastodon.social
@Jose_A_Alonso@mathstodon.xyz
@haskell@fosstodon.org