One reason why they're not the same is because the memory representation is different (sort of). This will break FFIs if you allow reordering the tuple arbitrarily.
I wrote a small thing for adding a `#doc List.find` directive. However, I don't maintain it anymore since I think it doesn't see much use and it's work to keep up on OCaml compiler internals changes (and it's my impression it never picked up much adoption). https://github.com/reynir/ocp-index-top
In an electric car? Really? I don't know too much about electric cars, but it's my impression that gears and transmissions are completely unnecessary in an electric car. Please correct me if I am wrong.
> For example, if you are using a recent version of OpenSSH, you
may wish to explore using the ServerAliveInterval and
ServerAliveCountMax options to have the SSH client exit if it
finds itself no longer connected to the server. In many ways
this may be a better solution than the monitoring port.
I helped build a tar-backed filesystem for MirageOS[0]. It is definitely easiest to make it append-only. I did add in-place renaming, updates (of file content), pre-allocating a file and removing the last file.
We also scan the filesystem on boot and keep a mapping in-memory of file names to file metadata and block offsets, and update this memory representation when modifying the on-disk tar filesystem. If you have a lot of small files this is maybe not a great idea as you will be storing most in memory, though.
For the purpose we had in mind it worked fine: A content addressable mirror of package archives. The archives exist somewhere on the web and the package file has a link to the archive and a checksum. We can then download the package and store it by the checksum. This gives integrity that the tar filesystem does not offer. Removing the last file works great if you only have one download job. Otherwise if a download fails and it is not the latest file you can rename it to `failed/<hash>-<random>` and do garbage collection in the filesystem at a later point.
Update: interestingly, this was motivated after trying to use a (mostly) LittleFS-compatible filesystem which unfortunately didn't work very well for us at the time (bugs, poor performance).
It is possible to run Mirage in ARM under for example KVM or using the seccomp target.
There is as well an experimental bare-metal target for raspberry pi 4 called gilbraltar https://github.com/dinosaure/gilbraltar. A big obstacle there is the device drivers. It is very cool to run bare metal on an rpi4, but it would be cool to be able use the network interface too.
A big difference in my opinion is that projects like Mirage does not try to reimplement the same hardware drivers as the host system and instead implements much simpler drivers for virtual hardware.
For example, how do you write to a block device? You make a hypercall with a "handle", offset into the block device, the number of blocks to write and a pointer to memory to be written. There's no pretending it's a spinny disk with sectors and heads or what have you.
No, Reason's actual name is Reason. The Reason ML name is similar to Go's "golang" name -- to work around the SEO nightmare the choice of the name really is. Your comment is otherwise correct in that Reason is an alternative syntax for good 'ole OCaml.