Notions of Computation Determine Monads In this session, we investigate how describing effects algebraically generates most of the monads traditionally used to model said effects.

From 14:30 to 15:30 on Wednesday, March 18, the PLSL reading group will discuss "Notions of Computation Determine Monads" by Gordon Plotkin and John Power.

plsl.acp.sdu.dk/posts/2026-03-18-notions...

#PLSL #algebraicEffects #effectSystems #monads

C++Online 2026 Session: Monads Meet Mutexes

C++Online 2026 SESSION SPOTLIGHT: Monads Meet Mutexes by Arne Berger

Find out more and register your ticket today!

#coding #cplusplus #cpp #monads

Monads Unmasked: The Category Theory You're Already Using Without Knowing - Java Code Geeks Monads Unmasked by showing they're design patterns you already use daily. Learn why Java's Optional, JavaScript's Promise

Monads Unmasked: The Category Theory You’re Already Using Without Knowing Mention “monads” to most developers and watch their eyes glaze over. The term carries baggage: intimidating mathemati...

#Core #Java #Design #Patterns #Functional #Programming #Monads

Origin | Interest | Match

Free - Higher-Kinded Types and Optics for Java Explore Higher-Kinded Types (HKTs) and Optcs in Java with the Higher-Kinded-J library. Learn about Functors, Applicatives, Monads, Transformers, practical functional patterns, and how to write cleaner, more composable Java code for your projects using Optics.

Practical Free monads in Java

higher-kinded-j shows you how to:
• Build composable DSLs
• Transformations as interpreters
• Stack-safe (10k+ ops verified)
• Test effectful code purely

Complete guide:
higher-kinded-j.github.io/monads/free_...

#Java #FunctionalProgramming #Monads #AdvancedJava

0 o a o © What's New in Higher-Kinded-J 0.2.0 Massive Optics Expansion This release dramatically expands the optics library with 6 new optic types and dozens of utility classes: + Fold, Getter, Setter: New fundamental optic types for read-only queries, single-element access, and write-only modifications + Indexed Optics: Position-aware transformations with IndexedTraversal , IndexedFold ,and IndexedLens + Filtered Traversals: Compose predicates directly into optic chains with filtered() and filterBy() + Limiting Traversals: Focus on specific portions of lists with taking() , dropping() , takingwhile() , slicing() , etc. + PartsOf: Transform all focused elements as a single list with operations like sorted() , reversed() , distinct() + Fluent API: New operator-style API with Free Monad DSL for building composable optic programs with multiple interpreters New Functional Programming Primitives + FreeMonad: Build domain-specific languages (DSLs) with stack-safe execution and multiple interpreters + Trampoline: Stack-safe recursion support for tail-call optimization + Const Functor: Phantom type parameter support for advanced type-level programming + Alternative Type Class: Choice and failure operations for applicative functors Enhanced Type Classes + Monoid: New methods ( firstOptional() , lastOptional() , maximum() , minimum() ) and instances (Long, Double) + Monad: Added flatMap2-5 for sequencing multiple monadic values with effectful combining functions

Six new Composable Optics and a FreeMonad DSL all in the latest #higher-kinded-j release

check it out higher-kinded-j.github.io/optics/optic...

#Java #FunctionalProgramming #Monads #Optics

Exploring Arrows for sequencing effects Monads are <em>one</em> way to sequence effects, but they're not the only way!

Don't get too hung up on #Monads, there are other ways to sequence effects; including Arrows; and they provide even better static analysis!

Let me know what you think :)

#Haskell

chrispenner.ca/posts/arrow-...

The discussion shows monads are powerful for composition but challenging to learn. Understanding specific instances & their practical benefits in context seems crucial for wider adoption. #Monads 6/6

Kevin Hoffman's Blog - Making a MUD out of Monad Stacks An experiment to isolate mud side effects from pure functions

Just like everyone else in the universe, after waking up from a procedure, I felt compelled to explore how monad transformers can make writing a MUD easier and more elegant.

#MUD #Haskell #Monads

That's totally normal, right?? Right??

kevinhoffman.blog/post/monad_m...

How to pass the invisible One of the enduring challenges in software programming is this: “How do we pass the invisible?” Loggers, HTTP request contexts, current locales, I/O handles—these pieces of information are needed throughout our programs, yet threading them explicitly through every function parameter would be unbearably verbose. Throughout history, various approaches have emerged to tackle this problem. Dynamic scoping, aspect-oriented programming, context variables, and the latest effect systems… Some represent evolutionary steps in a continuous progression, while others arose independently. Yet we can view all these concepts through a unified lens. ## Dynamic scoping Dynamic scoping, which originated in 1960s Lisp, offered the purest form of solution. “A variable's value is determined not by where it's defined, but by where it's called.” Simple and powerful, yet it fell out of favor in mainstream programming languages after Common Lisp and Perl due to its unpredictability. Though we can still trace its lineage in JavaScript's `this` binding. ;; Common Lisp example - logger bound dynamically (defvar *logger* nil) (defun log-message (message) (when *logger* (funcall *logger* message))) (defun process-user-data (data) (log-message (format nil "Processing user: ~a" data)) ;; actual processing logic… ) (defun main () (let ((*logger* (lambda (msg) (format t "[INFO] ~a~%" msg)))) (process-user-data "john@example.com"))) ; logger passed implicitly ## Aspect-oriented programming AOP structured the core idea of “modularizing cross-cutting concerns.” The philosophy: “Inject context, but with rules.” By separating cross-cutting concerns like logging and transactions into aspects, it maintained dynamic scoping's flexibility while pursuing more predictable behavior. However, debugging difficulties and performance overhead limited its spread beyond Java and .NET ecosystems. // Spring AOP example - logging separated as cross-cutting concern @Aspect public class LoggingAspect { private Logger logger = LoggerFactory.getLogger(LoggingAspect.class); @Around("@annotation(Loggable)") public Object logMethodCall(ProceedingJoinPoint joinPoint) throws Throwable { String methodName = joinPoint.getSignature().getName(); logger.info("Entering method: " + methodName); Object result = joinPoint.proceed(); logger.info("Exiting method: " + methodName); return result; } } @Service public class UserService { @Loggable // logger implicitly injected through aspect public User processUser(String userData) { // actual processing logic… return new User(userData); } } ## Context variables Context variables represent dynamic scoping redesigned for modern requirements—asynchronous and parallel programming. Python's `contextvars` and Java's `ThreadLocal` exemplify this approach. Yet they still suffer from runtime dependency and the fact that API context requirements are only discoverable through documentation. Another manifestation of context variables appears in React's contexts and similar concepts in other UI frameworks. While their usage varies, they all solve the same problem: prop drilling. Implicit propagation through component trees mirrors propagation through function call stacks. # Python contextvars example - custom logger propagated through context from contextvars import ContextVar # Define custom logger function as context variable logger_func = ContextVar('logger_func') def log_info(message): log_fn = logger_func.get() if log_fn: log_fn(f"[INFO] {message}") def process_user_data(data): log_info(f"Processing user: {data}") validate_user_data(data) def validate_user_data(data): log_info(f"Validating user: {data}") # logger implicitly propagated def main(): # Set specific logger function in context def my_logger(msg): print(f"CustomLogger: {msg}") logger_func.set(my_logger) process_user_data("john@example.com") ## Monads Monads approach this from a different starting point. Rather than implicit context passing, monads attempt to encode effects in the type system—addressing a more fundamental problem. The `Reader` monad specifically corresponds to context variables. However, when combining multiple effects through monad transformers, complexity exploded. Developers had to wrestle with unwieldy types like `ReaderT Config (StateT AppState (ExceptT Error IO))`. Layer ordering mattered, each layer required explicit lifting, and usability suffered. Consequently, monadic ideas remained largely confined to serious functional programming languages like Haskell, Scala, and F#. -- Haskell Logger monad example - custom Logger monad definition newtype Logger a = Logger (IO a) instance Functor Logger where fmap f (Logger io) = Logger (fmap f io) instance Applicative Logger where pure = Logger . pure Logger f <*> Logger x = Logger (f <*> x) instance Monad Logger where Logger io >>= f = Logger $ do a <- io let Logger io' = f a io' -- Logging functions logInfo :: String -> Logger () logInfo msg = Logger $ putStrLn $ "[INFO] " ++ msg processUserData :: String -> Logger () processUserData userData = do logInfo $ "Processing user: " ++ userData validateUserData userData validateUserData :: String -> Logger () validateUserData userData = do logInfo $ "Validating user: " ++ userData -- logger passed through monad runLogger :: Logger a -> IO a runLogger (Logger io) = io main :: IO () main = runLogger $ processUserData "john@example.com" ## Effect systems Effect systems emerged to solve the compositional complexity of monads. Implemented in languages like Koka and Eff, they operate through algebraic effects and handlers. Multiple effect layers compose _without ordering constraints_. Multiple overlapping layers require no explicit lifting. Effect handlers aren't fixed—they can be dynamically replaced, offering significant flexibility. However, compiler optimizations remain immature, interoperability with existing ecosystems poses challenges, and the complexity of effect inference and its impact on type systems present ongoing research questions. Effect systems represent the newest approach discussed here, and their limitations will be explored as they gain wider adoption. // Koka effect system example - logging effects flexibly propagated effect logger fun log-info(message: string): () fun log-error(message: string): () fun process-user-data(user-data: string): logger () log-info("Processing user: " ++ user-data) validate-user-data(user-data) fun validate-user-data(user-data: string): logger () log-info("Validating user: " ++ user-data) // logger effect implicitly propagated if user-data == "" then log-error("Invalid user data: empty string") fun main() // Different logger implementations can be chosen dynamically with handler fun log-info(msg) println("[INFO] " ++ msg) fun log-error(msg) println("[ERROR] " ++ msg) process-user-data("john@example.com") * * * The art of passing the invisible—this is the essence shared by all the concepts discussed here, and it will continue to evolve in new forms as an eternal theme in software programming. *[AOP]: aspect-oriented programming

For Comprehension - HKJ Higher-Kinded Types for Java Explore Higher-Kinded Types (HKTs) in Java with the Higher-Kinded-J library. Learn about Functors, Applicatives, Monads, Transformers, practical functional patterns, and how to write cleaner, more composable Java code for your projects.

✨The new For-Comprehension in #higher-kinded-j can de-sugar complex monadic chains into a simple, sequential script.
It supports: ➡️ Generators (from) ➡️ Bindings (let) ➡️ Guards (when) ➡️ Final yield
#Java #FP #FunctionalProgramming #Monads #OpenSource #HKJ
higher-kinded-j.github.io/for_comprehe...

Original post on mstdn.social

When Kyle Simpson wrote a book about monads, "Unwrapping Monads & Friends," I decided to read it. I'm done with monads in my life at this point, but I was curious how he tackled this. Kyle has a talent to nail various subjects without pretentiousness (and Lord only know how much of that there is […]

@annakaharris.bsky.social and, if what we call consciousness DOES "arise" or "emerge" with the beginning of life, in avoidance/survival, would this necessarily amount to an illusion (a la Dennett) or at least problematic dualism? #monads

When your types align perfectly, and the monads sing. 🎶 #ocaml #monads #functional #ocsigen

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

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

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?

Monadic composition in property testing can slow shrinking by 100x. Learn why and how to avoid it.
https://sunshowers.io/posts/monads-through-pbt/
#rust #testing #monads #performance #programming

softinio - Twitch Software Engineer with interests in Scala, Haskell, Swift Language, Neovim and NixOS.

Functional Programming in #Scala part 3 of 3 about to start (9am Pacific), you can watch on Twitch too:

www.twitch.tv/softinio

There will be mentions of #Monads and #Effect systems!

#BayAreaScala #Meetup #Course #FunctionalProgramming

cc @makingthematrix.github.io @scala.intellijidea.com

are real numbers a monad?

they're definitely a monoid, and my intuition says they're not functor-y enough to be a monad, but that's not useful enough when i only halfway understand these concepts

#math #monads

#Windowless #Monads from #Liebnitz #Liebniz composed of #copyright #logos "c" in a #circle, each c is a monadic "self", or energy plasma orb, or copyright symbol, inner c is a circle that is incomplete #digitalart#

#Windowless #Monads from #Liebnitz #Liebniz composed of #copyright #logos "c" in a #circle, each c is a monadic "self", or energy plasma orb, or copyright symbol, inner c is a circle that is incomplete #digitalart#

Ranting about Monads for fifty minutes. - nicuveo on Twitch nicuveo went live on Twitch. Catch up on their Software and Game Development VOD now.

Someone redeemed the "rant about monads" perk on my channel, so... here's 50 minutes of me ranting about monads and trying to convey an intuition for them. Warning: a bit loud, it's a rant after all. :D

www.twitch.tv/nicuveo/v/23...

#haskell #monads #adventofcode

📦 Monads in C#: A Rigorous Exploration with Practical Examples In this exposition, we will rigorously explore the notion of monads and demonstrate their application in C# through a detailed example.

If you have noticed that #csharp has been enriched by functional programming, this topic will be of interest to you.

#Monads in C#: A Rigorous Exploration with Practical Examples.

www.linkedin.com/pulse/monads...

The Monads Hurt My Head --- But Not Anymore | The n-Category Café Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older…

🤕 The Monads Hurt My Head --- But Not Anymore | The n-Category Café

https://buff.ly/3YUyPu9

#monads #math

Original post on masto.ai

Wow! What a day! This is the second video leaving the Rookies today and it is only the intro to my "Monads are no Nomads" video. There are a ton of shorts over this topic on JESPROTECH everyone! Thank you for watching and have a good one! #kotlin #haskell #monads […]

Wow! What a day! This is the second video leaving the Rookies today and it is only the intro to my "Monads are no Nomads" video. There are a ton of shorts over this topic on JESPROTECH everyone! Thank you for watching and have a good one! #kotlin #haskell #monads: www.youtube.com/watch?v=x2aF...

I need an aside here to explain what #FunctionalProgramming is all about without having to descend into #Monads or #Monoids or #Functors or, you know, everything.

4/

The second video can be found here: #monad #monads #monoids #monoid #kotlin #haskell https://dai.ly/x97nue2

I just posted on DailyMotion three new videos with sound improved and in vertical format! Watch them all there. One is about resillience in project arrow and the other is a compilation of all the vertical video shorts I created for my monads video 🧵. #monads #kotlin #haskell https://dai.ly/x97nsec

Dailymotion

The second video can be found here: #monad #monads #monoids #monoid #kotlin #haskell dai.ly/x97nue2

Dailymotion

I just posted on DailyMotion three new videos with sound improved and in vertical format! Watch them all there. One is about resillience in project arrow and the other is a compilation of all the vertical video shorts I created for my monads video 🧵. #monads #kotlin #haskell dai.ly/x97nsec

This is the next entry in the Late Bloomers playlist everyone! This one reached 100 views recently and it stood for a while time in the Rookies playlist. Only later people found the video interesting. Thank you! #monads #monoids #functors #kotlin #haskell youtu.be/_NVWfjI_LjM?...