So first things first, we'll want to define some intermediate representation, the serde.ml language.
Then we can make something that reads/writes to that from some specific format (json, toml, etc).
Then we can make something that transforms serde.ml into typed ml data.
Okay, so this is what I've got so far.
Here's the serde.ml data model, more or less fitting the basic types you can build up (or that come with) #ocaml:
Now on its own it isn't very interesting, its just a small AST for data structures.
The magic is that this is really an ✨intermediate representation✨
A shared interface really, between the ser and de parts of serde.
And on the other side we have modules that consume this IR and spit out other formats like JSON, s-expressions, TOML, KDL, XML, what have you.
I haven't sketched any of those yet enough to show a screenshot.
yeah, no. these meta-quotation libraries are unusable to me. I'll need tons more documentation and examples on how to do common things. I'm getting too spoiled by the amazing efforts in Rust to keep libraries well documented.
Going back to ast_builder.
so i got a deriver for serializers into the serde.ml language somewhat working, and this is already making it so much eaiser to test stuff -- viva la #metaprogramming!
fork yes! its valid #ocaml now. i think.
it also derives:
* newtypes
* tuples
* variants (unit, tuple, and record ones)
and knows how to follow modules/etc
ok, will add support for records next
friggin' brew. we're back on track. I wrote a sexpr serializer to iron out the serializer implementator interface, and it feels good!
(minus all the explicit first-class module signatures type escaping)
the important bits is that this is what you normally write as a user:
type t = { ... } [@@deriving serializer]
and then you can call
t |> serialize_t |> Serde_sexpr.to_string
wanna go to json? just change to Serde_json.to_string
maybe someone will finally implement a deriving(debug) with this!
but for authors of serializers, there's a few things that always get in the way:
1. error handling (esp. over collections)
2. mapping over the serde.ml data definition language
3. parametrizing over the kind of output you want to have (usually a string, but could be a buffer/channel that goes straight to stdout/disk/network)
all of those are provided by the Ser.Mapper interface, which is created at runtime based on the definition of the serializer you are using.
See this cursed module: https://github.com/ostera/serde.ml/blob/main/serde/ser.ml#L163-L185
uuuuugh yojson why don't you have a clean clear exported ast WHY
folks, we need more _type-only_ packages. like we have for http type defs.
in any case, here we go: one line change and we got serialization to json.
sweet.
Leandro
