Guarded Methods in OCaml (2025)
1–8 of 8 posts
Re: Guarded Methods in OCaml (2025)
#2Nice article, but I don’t fully understand why the author argues for such an aversion to static functions.
> Moreover, it breaks the systematic approach of sending messages to an instance (often presented as one of the key arguments in favor of object-oriented programming).
Is this just a matter of “the code will become spaghetti once too many classes/methods/implementations exist”? And, conversely, is a non-static method with a constrained, i.e. somehow different type (or also the approach of moving a method outside of the class proper) not more confusing?
Re: Guarded Methods in OCaml (2025)
#3Cool to see this pop up today.
I'm building a new language and just a couple of days ago the concept of guard methods came up as I was trying to tighten up equality semantics to be more like Swift.
Things like Array.contains() only work if the element type implements the Equatable interface, so it would be a guard method. Maybe something like:
class Array {
contains(value: T): boolean where T extends Equatable { ... }
}
class Array {
contains(this: Array, value: T): boolean { ... }
}
Re: Guarded Methods in OCaml (2025)
#4> Although guarded methods seem necessary, unfortunately, I don’t know of any mainstream languages that allow their definition.
C++ has this feature. When you define a template class, you can use SFINAE (or, in modern C++, concepts) to make it so that certain methods only exist if the template parameter meets certain requirements.
(Though even this is often unnecessary - for something like your `flatten` example, you could just go ahead and define it unrestricted. Methods of template classes are typechecked lazily - in other words, they don't need to successfully typecheck unless they're called. For this specific use case, SFINAE/concepts would just make the error message nicer.)
Rust also has this feature, with conditional impls.
Re: Guarded Methods in OCaml (2025)
#5> Although guarded methods seem necessary, unfortunately, I don’t know of any mainstream languages that allow their definition. C++ has this feature. When you define a template class, you can use SFINAE (or, in modern C++, concepts) to make it so that certain methods only exist if the template parameter meets certain requirements. (Though even this is often unnecessary - for something like your `flatten` example, you…
> Rust also has this feature, with conditional impls.
Rust's approach seems more similar to the approach described in the section on extension methods, which the author admits solves the problem but doesn't like the implications for encapsulation (which isn't a problem in Rust, as long as you're writing this method in the same crate as the type definition). But Rust also doesn't have classic Java-style classes, so the requirement to "keep the member definition within the class" is already meaningless in Rust terms.
Re: Guarded Methods in OCaml (2025)
#6> Although guarded methods seem necessary, unfortunately, I don’t know of any mainstream languages that allow their definition. C++ has this feature. When you define a template class, you can use SFINAE (or, in modern C++, concepts) to make it so that certain methods only exist if the template parameter meets certain requirements. (Though even this is often unnecessary - for something like your `flatten` example, you…
> Rust also has this feature, with conditional impls. Rust's approach seems more similar to the approach described in the section on extension methods, which the author admits solves the problem but doesn't like the implications for encapsulation (which isn't a problem in Rust, as long as you're writing this method in the same crate as the type definition). But Rust also doesn't have classic Java-style classes, so th…
Idiomatically Rust explicitly prefers to make a type more generic, for example it's fine to talk about a HashMap for some arbitrary user defined type Goose with no traits, and Rust will even cheerfully make you one... but you can't put any key+value pairs into that hash map because Goose isn't Eq [or Hash] so all the APIs for actually inserting or modifying the data don't exist on this type.
In contrast C++ won't even let you have std::unordered_map because it wants to know how to compare and hash the keys before making the type at all.
Re: Guarded Methods in OCaml (2025)
#7Nice article, but I don’t fully understand why the author argues for such an aversion to static functions. > Moreover, it breaks the systematic approach of sending messages to an instance (often presented as one of the key arguments in favor of object-oriented programming). Is this just a matter of “the code will become spaghetti once too many classes/methods/implementations exist”? And, conversely, is a non-static m…
I'm learning F#, not sure if this generalises to ocaml too. In F#, there is no function overloading, but there is method overloading.
F# lacks higher-kinded types, but it's possible to roll your own using techniques from the article.
https://robkuz.github.io/Higher-kinded-types-in-fsharp-Intro...
https://github.com/G-Research/TypeEquality
This gets you a bit closer to the power of Haskell.
It's code golf - f# community consensus is to prefer simple explicit code. But it avoids runtime type checks, so can be a performance optimisation.
Re: Guarded Methods in OCaml (2025)
#8The general term for this is an indexed type. Specifically what is shown here is indexed codata. Indexed data is more commonly known as generalized algebraic data types (GADTs), which encode equality constraints at construction.
GADTs are well established in FP, but codata in general is not[^1]. As far as I can tell this is partly historical and partly cultural. (Codata is basically OO. Recent FP languages, like Idris, have explicit support for codata.)
More in my book: https://functionalprogrammingstrategies.com/
^[1]: The degenerate form of codata is the function, which FP languages do tend to support very well.