Yaron Minsky

I mean, ocaml has a lot of features that depend on pretty deep build system integration. Other build systems are free to implement them, but just haven't yet.

But I think it's quite important, in that it finally delivers on the initial promise of the ML module system that we've been waiting decades for.

Parameterized libraries does something much better. It gives you a scheme for managing parameters at a whole-codebase level, where you specify them finally when you go to build an executable. It requires cooperation between the language and the build system to make this all work.

What I was asking for in that old thread was a way to do this at the level of a multi-file library, just functorize the whole thing in one fell swoop.

But this means you have to be very explicit about dependencies, and you build up an ever more complex representation of the dependency graph of your code.

I was initially asking for something pretty simple. A functor is basically a module with some parameters. You can go compilation unit by compilation unit (i.e., file by file), functorizing each one.

The basic issue is that OCaml's module system, despite being a really good foundation for building modular software, has fundamental scaling problems. There's just too much syntactic overhead involved in parameterizing (in OCaml jargon, functorizing) a complex codebase.

We've finally landed a full version internally (coming to an OxCaml near you soon!) of a new feature called parameterized libraries.

It's basically an answer to a problem I first ran into 23 years ago. Here's a thread about it on the caml-list.

inbox.vuxu.org/caml-list/10...

Signals and Threads Podcast Listen in on Jane Street’s Ron Minsky as he has conversations with engineers working on everything from clock synchronization to reliable multicast, build systems to reconfigurable hardware. Get a pee...

A new epsiode of Signals and Threads has just dropped: "The Thermodynamics of Trading". I got to talk to Dan Pontecorvo from our physical engineering team about the complex work that goes into our physical spaces to make the work we do at Jane Street possible.

signalsandthreads.com/the-thermody...

YouTube video by Jane Street The Saga of Multicore OCaml

I had a lot of fun giving this talk in Singapore about the many-years-long saga of multicore OCaml, and in particular, the work over the least 2.5 years of getting it ready for production work within Jane Street's walls.

www.youtube.com/watch?v=XGGS...

My approach so far is to treat AI code assistants as an extension of “a large team with communication challenges working on the same codebase.” You need better tools to clean up the local optima that individual agents get stuck in. See prune and merlint:
discuss.ocaml.org/t/ann-new-to...

Some of the heavier stuff (modes, unboxed types, parallelism) isn't mature enough yet to even propose. But we should be continuing to eliminate unnecessary differences wherever we can.

Polymorphic Parameters by voodoos · Pull Request #13806 · ocaml/ocaml This upstreaming PR adds the possibility to have function parameters with polymorphic types in the language. This work was originally done by @lpw25 in Jane Street's fork of the compiler with e...

Yet another small OCaml/OxCaml diff has been squished! Polymorphic parameters has just gotten merged upstream:

github.com/ocaml/ocaml/...

There's more to go (include functor, for example: github.com/ocaml/RFCs/p...), but it's nice to see more progress in this space.

Yeah, the need to "control the class" is the anti-modularity I'm trying to get away from.

Btw, the same "newtype" approach works with OCaml and deriving: you can always define a new type alias and attach the necessary functionality to that. But, like the newtype thing in Haskell, it's an awkward hack.

I'm looking forward to modular implicits lifting that misfeature. It seems like the Haskell and Rust approach has the same problem as the current OCaml approach.

Thanks! That clarifies things for me.

I do think the orphan rule is itself not great for modularity. One of the antimodular parts of the current OCaml experience is that you can't add a new deriving rule without intrusively changing the module that defines the type in question.

But I think the right solution for that is for your set type to have a type parameter that identifies the comparator, rather than to make a core language feature compose poorly.

Some Haskell folk will argue that this kind of global coherence is a food feature, since It guarantees that any two integer sets use the same comparison function, so operations like set union actually work.

I'm fairly ignorant about Haskell things, but my understanding is that coherence is truly global. So in a given program, each type can resolve to only one typeclass instance. Different programs can do this in different ways, but two libraries that make different choices can't be linked together.

Which is to say, I can have two different pieces of code that make different decisions about how to resolve type classes, and even if those decisions are never surfaced from one to the other, it's impossible to build an executable that combines both.

I think it's actually antimodular in a really boring pedestrian way that has nothing to do with the ml modules.

The main reason we don't have modular implicits is that doing it well is hard, and there's a lot of other great stuff people are working on!

The problem I hear people raise with typeclasses is that global coherence is anti-modular. Which is why that constraint is lifted in the modular implicits design.

They do prefer a different solution though. The modular implicits paper gives a good sketch of the direction that seems most likely for ocaml.

www.cl.cam.ac.uk/~jdy22/paper...

I'm somewhat surprised by this critique. This isn't the argument against typeclasses that I hear in ocaml circles.

AFAICT, the core ocaml team is largely convinced that some form of ad hoc polymorphism would be a good idea.

I'm curious what other other ideas people are working on!
🧵3/3

So, what direction does that push in?

Perhaps towards features like refinement types, or dependent types?

And perhaps towards multiple views of source code, where there's more written to support the verification process, which is mostly dropped for the human view.
🧵2/3

We're starting to think about how to evolve OCaml to be a more effective language for agentic programming.

One intuition here is that agents change what's important in 2 ways:

- the toil of writing matters less
- the ease of understanding and verifying matters more
🧵1/3

So, what direction does that push in?

Perhaps towards features like refinement types, or dependent types?

And perhaps towards multiple views of source code, where there's more written to support the verification process, which is mostly dropped for the human view.
🧵2/3