We recently restructured our standard libraries at Jane Street in a
way that eliminates the difference between Core_kernel
and Core
and we’re happy with the result. The new layout should reach the open
source world before the end of the year.
Overview
For many years, Jane Street has had two variants of our Core
standard library:
-
Core_kernel
, which extendsBase
, and works on Javascript and Windows. -
Core
, which extendsCore_kernel
, adding functionality that uses theUnix
library.
We eliminated the distinction between Core
and Core_kernel
by
moving (mostly non-portable) functionality from Core
out to
standalone libraries, and then simply renamed Core_kernel
as Core
.
Rationale
The upsides of this change are clear enough:
-
It’s simpler. Instead of three different flavors of our standard library, there are just two, hopefully with clearer purposes.
-
It encourages portability. The fact that Core wouldn’t work on JavaScript and Windows meant that lots of libraries that could have been portable weren’t. This change should fix that.
This change is the culmination of work that has been going on for
years. We had already moved most of the functionality out of Core
,
into either Core_kernel
or to standalone libraries that depended on
Core
. In the end, there wasn’t that much code that distinguished
Core
from Core_kernel
, so the change is smaller than it seems.
Hopefully, this all makes the differences between Base and Core clearer. In particular:
Base
is lighter, much faster to compile, and more stable.Core
is more extensive, having both more useful libraries and data-structures, as well as some more useful functionality broadly integrated into it, like pervasive integration ofbin_prot
andbase_quickcheck
.
And both of them are fully portable.
Adapting code to the change
The recommended way to adapt code to this change is to replace
Core_kernel
with Core
and then to build with deprecation errors
enabled. We have left behind @@deprecated
annotations throughout
Core
for functionality that was moved into standalone libraries.
So, you should get deprecation messages if your code needs further
updates.
For example, if you use Core.Date.format
, you will get a deprecation
message:
Error (alert deprecated): Core.Date.format
[since 2021-03] Use [Date_unix]
Here, Date_unix
is the name of the new standalone library that
extends Core.Date
with Unix-dependent functionality, include
Date_unix.format
.
Here’s a list of the modules that moved from Core
to a standalone
library:
Old name | New name |
---|---|
Core.Command | Command_unix |
Core.Date | Date_unix |
Core.Filename | Filename_unix |
Core.Signal | Signal_unix |
Core.Sys | Sys_unix |
Core.Thread | Core_thread |
Core.Time | Time_unix |
Core.Time_ns | Time_ns_unix |
Core.Unix | Core_unix |
Releasing this change in the main opam repository
This change is good but is not backward compatible. As a result, some care will be needed to release it into the opam repository. We have a few ideas for how to make the transition smoother, but we haven’t settled on a concrete plan yet. We plan to work more proactively on it starting from September.