Login

Recent searches

No recent searches

Search options

Only available when logged in.
fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

10K
active users

fosstodon.org: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.5

#ocaml

20 posts16 participants0 posts today
Public
OCaml

OCaml Weekly News, 11 Mar 2025: * OCaml projects utilizing Category theory
* Docker base images and OCaml-CI support for OCaml lt 4.08
* ocamlmig, a tool to rewrite ocaml code, and complement ~[@@deprecated]~
* Ortac 0.6.0 improve bug reporting
* Dune Developer Preview Updates
* ppxlib.0.36.0
* I created an OCaml grammar for ANTLR4 (Earley parser compatible)
* Melange 5.0
* Other OCaml News alan.petitepomme.net/cwn/2025. #OCaml #OCamlPlanet

alan.petitepomme.netOCaml Weekly News
Public
OCaml

Learning OCaml: Functions without Parameters: A couple of days ago I noticed on OCaml’s Discord server that someone was
confused by OCaml function applications (invocations) like these:
print_newline ()

read_input ()

To people coming from “conventional” programming languages this might look like
calling a function/method without any arguments. (e.g. foo() in Python) Of course,
function application in OCaml is quite different from JavaScript,… batsov.com/articles/2025/03/02 #OCaml #OCamlPlanet

Public
OCaml

Learning OCaml: Matching Anything or the Lack of Anything: I’ve noticed that some newcomers to OCaml are a bit confused by code like the following:
let () = print_endline "Hello, world"

let _ = foo bar

Both of those are forms of pattern matching, but one of them is a lot stricter
than the other. In OCaml () is the single value of the unit type that
indicates the absence of any meaningful value. You can think of it as something like void in
other… batsov.com/articles/2025/02/27 #OCaml #OCamlPlanet

Public
OCaml

Simple Ways to Run OCaml Code: When people think of OCaml they are usually thinking of compiling code to a
binary before they are able to run it. While most OCaml code is indeed compiled
to binaries, you don’t really need to do this, especially while you’re learning
the language and are mostly playing with small exercises.

Imagine you have something like this in a file named hello.ml:
let () = print_endline "Hello, world!"

You can compile this if… batsov.com/articles/2025/02/23 #OCaml #OCamlPlanet

Public
OCaml

Announcing Melange 5: We are excited to announce the release of Melange 5, the compiler for OCaml
that targets JavaScript.

A lot of goodies went into this release! While our focus was mostly on features
that make it easy to express more JavaScript constructs and supporting OCaml
5.3, we also managed to fit additional improvements in the release: better
editor support for Melange externals, code generation improvements, and
better compiler output for… melange.re/blog/posts/announci #OCaml #OCamlPlanet

melange.reAnnouncing Melange 5 | SandtracksThe official blog for the Melange project
Public
洪 民憙 (Hong Minhee)

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

hackers.pub · Monads: Beyond Simple Analogies—Reflections on Functional Programming ParadigmsWhile 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?
Public
洪 民憙 (Hong Minhee)

Monads: Beyond Simple Analogies—Reflections on Functional Programming Paradigms

hackers.pub/@hongminhee/2025/m

hackers.pub · Monads: Beyond Simple Analogies—Reflections on Functional Programming ParadigmsWhile 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#monads
Public
OCaml

OpenAI and structured outputs from OCaml: What makes this approach special?

OpenAI offers a way to have (relatively) typed communication through structured outputs. A json schema must be passed alongside the prompt. And the answer is guaranteed to follow that schema.

When working with OpenAI’s structured outputs, you typically need to:

* Define your data structures
* Create a JSON schema that describes these structures
* Parse the API… tech.ahrefs.com/openai-and-str #OCaml #OCamlPlanet

Public
OCaml

Feature Parity Series: Statmemprof Returns!: Welcome to part two of our feature parity series! In it, we present returning features that were originally lost when OCaml gained multicore support. The addition of multiple domains means that the underpinning design decisions behind certain features have had to change significantly, and work is ongoing to adapt them and return them to OCaml 5.

One of these features is memory profiling, which, after much… tarides.com/blog/2025-03-06-fe #OCaml #OCamlPlanet

Public
Bozhidar Batsov (a.k.a. Bug)

Today I came across ECaml (github.com/janestreet/ecaml) - a project that allows you to write #Emacs plugins in #OCaml. While, I don't have any issues with Elisp, I'll definitely check it out at some point. I'm guessing Jane Street are using it for their internal Emacs plugins.

Writing Emacs plugin in OCaml. Contribute to janestreet/ecaml development by creating an account on GitHub.
GitHubGitHub - janestreet/ecaml: Writing Emacs plugin in OCamlWriting Emacs plugin in OCaml. Contribute to janestreet/ecaml development by creating an account on GitHub.
ExploreLive feeds
About