Future Posts
Post 1
As long as we have a way to associate each module with “what a program does” we
can write secure software. But the standard library of OCaml does not have the
granularity make this association useful. The use of the Obj module, for
example, says that “what a program does” is “anything”. We can either prevents
the use of Obj, or partition the standard library such that Obj and other
modules like it are separated into an unsafe section.
In OCaml you cannot access any resource without going through the standard library or using FFI.
Additionally through a technique pioneered at Jane Street you can use the built-in “alert” with some light use of the OCaml “alert” system, you can force a program to get all of its functions, values through named modules.
If only there were a programming languages where you could inspect the code to
ascertain what it does then we’d have the rigour. Let’s say you have source code
that reads from the standard input stdin. You know immediately that you have a
class of vulnerabilities
conscious, cross-platform products. The minimal table stakes are being able to
separate some of a code base into platform specific code. For example, code that
reads the standard input stdin isn’t going to work in an Android application.
You need to have the ability to identify which code will work on what platform.
Best would be having a code tool performing that automatically rather than the
user having to partition everything themselves.
Since you must access libraries with OCaml modules, and I’ll get to how
MlFront does this a bit later.
Post 2
The one name to rule them all
The opam package name is the same as the library name which is the same as the module name.
Among the three consumers of names (opam, findlib and OCaml) only OCaml places a strong restrictions on naming. So the one name is the OCaml module name.
That leaves what to do for subprojects of subprojects (ex. cohttp-curl-lwt).
That requires cramming the subprojects into the OCaml module name. So use the
suffix CurlLwt rather than -curl-lwt.
Eventually you’ll start pretending the complexity is really “flexibility”.
Perhaps you can discern a pattern. Once you use OCaml enough, you stop caring. Other people call that Stockholm Syndrome.
You can use the ocurl “findlib packages”, “opam packages” … all referring to
the same thing. It was purely unnecessary complexity. , and MlFront is a
partial answer to those problems.
MlFront does not run on its own. It is a framework that needs to be embedded
in build tools. DkCoder is the only build tool that uses MlFront (in fact,
MlFront is the refactored core of DkCoder), but the hope is that other OCaml
build tools like Dune can make use of MlFront.
Post 3
MlFront creates OCaml source code as a side-effect. PPX code gen is the
conventional OCaml way to programmatically create code which operate on one
.ml module’s AST. MlFront code gen operates on a view of the project’s
module hierarchy.
