#OCaml

Compsci Weekly

@compsci_discussions@mastodon.social

Roguetype: The first ever roguelike written in the OCaml type system

https://github.com/Octachron/roguetype

Discussions: https://discu.eu/q/https://github.com/Octachron/roguetype

#compsci #ocaml #plt #programming

hannes

@hannesm@mastodon.social

Meet Mollymawk, our web UI for orchestrating #MirageOS unikernels, funded by NLnet @NGIZero https://blog.robur.coop/articles/mollymawk-first-milestone.html #OCaml #unikernel

hannes

@hannesm@mastodon.social

Meet Mollymawk, our web UI for orchestrating #MirageOS unikernels, funded by NLnet @NGIZero https://blog.robur.coop/articles/mollymawk-first-milestone.html #OCaml #unikernel

hannes

@hannesm@mastodon.social

Meet Mollymawk, our web UI for orchestrating #MirageOS unikernels, funded by NLnet @NGIZero https://blog.robur.coop/articles/mollymawk-first-milestone.html #OCaml #unikernel

Anupam 《ミ》λ≡

@aj@id1.in

Ready to geek out over functional programming? Join us for the upcoming FPIndia Bangalore meetup!
https://hasgeek.com/fpindia/bangalore-fp-april-meetup/

#Bangalore #FunctionalProgramming #FPIndia #Meetup #India #Haskell #PureScript #OCaml #Elixir #Clojure #Scala

Compsci Weekly

@compsci_discussions@mastodon.social

Roguetype: The first ever roguelike written in the OCaml type system

https://github.com/Octachron/roguetype

Discussions: https://discu.eu/q/https://github.com/Octachron/roguetype

#compsci #ocaml #plt #programming

OCaml

@ocaml@mastodon.social

Pushing the opam-repository into a sustainable repository: The main opam-repository was only ever growing by collecting all releases of all packages. We worked hard on reducing the load for all clients by archiving packages. https://blog.robur.coop/articles/2025-03-26-opam-repository-archive.html?utm_source=dlvr.it&utm_medium=mastodon #OCaml #OCamlPlanet

hannes

@hannesm@mastodon.social

Dear everyone, we just published an article on our #opam-repository archival work https://blog.robur.coop/articles/2025-03-26-opam-repository-archive.html

Happy reading #OCaml #opam #sustainability

hannes

@hannesm@mastodon.social

Dear everyone, we just published an article on our #opam-repository archival work https://blog.robur.coop/articles/2025-03-26-opam-repository-archive.html

Happy reading #OCaml #opam #sustainability

ELLIOTTCABLE

@ELLIOTTCABLE@functional.cafe

Hi! New instance, new pinned post.

Send me cool people to follow (or introduce yourself!)

- leftists
- functional programmers, 'spcly #OCaml folks
- #Queer mfers, #BDSM, or #polyamory
- fans of #SystemicGames (#Factorio, #RimWorld, and the like)

come @ me :transHaskell:

Dinosaure

@dinosaure@mastodon.social

I'm really glad to share my last work about μTCP, #unikernels, effects and #OCaml 5. I talk about TCP/IP, #GADTs, and some useful data-structures. https://blog.robur.coop/articles/utcp_and_effects.html

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

洪民憙 (Hong Minhee)

@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?

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

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

洪民憙 (Hong Minhee)

@hongminhee@hackers.pub

The Elegant Power of Monads in Haskell

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 ()

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 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

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

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

洪民憙 (Hong Minhee)

@hongminhee@hackers.pub

The Elegant Power of Monads in Haskell

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 ()

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 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

José A. Alonso

@Jose_A_Alonso@mathstodon.xyz

Readings shared February 21, 2025. https://jaalonso.github.io/vestigium/posts/2025/02/21-readings_shared_02-21-25 #AI #Autoformalization #Coq #FunctionalProgramming #ITP #IsabelleHOL #LLMs #LeanProver #Math #OCaml #Rocq

José A. Alonso

@Jose_A_Alonso@mathstodon.xyz

Learn programming with OCaml (Algorithms and data structures). ~ Sylvain Conchon, Jean-Christophe Filliâtre. https://usr.lmf.cnrs.fr/lpo/lpo.pdf #OCaml #FunctionalProgramming

Haskell Weekly

@haskell_discussions@mastodon.social

Porting PFP from Haskell to OCaml

https://github.com/lewis-carson/PFPCaml

Discussions: https://discu.eu/q/https://github.com/lewis-carson/PFPCaml

#haskell #ocaml #programming

José A. Alonso

@Jose_A_Alonso@mathstodon.xyz

Readings shared January 3, 2025. https://jaalonso.github.io/vestigium/posts/2025/01/03-readings_shared_01-03-25 #ITP #Lean4 #IsabelleHOL #Coq #Rocq #Math #FunctionalProgramming #OCaml #Haskell #Python #AI #MachineLearning

José A. Alonso

@Jose_A_Alonso@mathstodon.xyz

Typechecking of overloading in programming languages and mechanized mathematics. ~ Arthur Charguéraud, Martin Bodin, Louis Riboulet. https://inria.hal.science/hal-04859446/document #OCaml #FunctionalProgramming

José A. Alonso

@Jose_A_Alonso@mathstodon.xyz

Storable types: free, absorbing, custom. ~ Basile Clément, Camille Noûs, Gabriel Scherer. https://inria.hal.science/hal-04859464/file/jfla2025-final54.pdf #OCaml #FunctionalProgramming

hannes

@hannesm@mastodon.social

We just published our funding structure and detailed income since the beginning of robur -- https://blog.robur.coop/articles/finances.html #cooperative #mirageos #ocaml #money #transparency -- and why we're doing what we're doing. :)

Sofie 🏳️‍🌈

@soupglasses@hachyderm.io

#introduction

Heyo!

My name is Sofie, and I love building things so it is nicer and easier to use!

I touch on subjects such as #nixos, #sysadmin, and how to generally make your life easier running servers.

I also love trying out a lot of different programming languages, big ones being #Rust, #Ocaml, and #Ruby right now!

My current pet project is https://github.com/imsofi/phenix

In my free time I also enjoy #boardgames and #radiocontrol.

Good to see you! :ablobfoxbongo:

Christopher League

@league@scholar.social

Reactivating — Hello! I’m into:
• Functional programming, especially #haskell, #ocaml, #elmlang, #purescript
• Proof systems & software correctness tools #coq, #idris, #agda, #rustlang
• Scientific data acquisition & analysis, #gpu frameworks
• Reproducible builds, #nixos, #nixpkgs
• Non-traditional families (#queer, interracial)
• #ADHD strategies & other #neurodivergent perspectives
• Black natural hair care, for Ms. 7yo
• #Classical & electronic music, dabbling at piano as a busy adult

yomimono, still on earth

@yomimono@wandering.shop

> ./masto.sh
>>> Welcome back to Mastodon!
>>> You are [yomimono]. You are in some sort of wandering shop.
>>> Behind you is a weirder earth (closed), just beyond which is a famous town of witches (also closed).

> inventory

>>> You have:
>>> a computer
>>> regrets

> order coffee

>>> ☕

> program computer

>>> You make a #unikernel in #ocaml using #mirageos .

> program computer

>>> You work on a #secretProject ! it involves #crossStitch and #embroidery.

> look cat

>>> which #cat?

> ALL