Diagnostics and file paths

Ecosystem
,
1

I made a single-file port of GitHub - Mesabloo/diagnose: A simple library for reporting compiler/interpreter errors from Haskell to OCaml. It is similar to Grace and asai discussed in [ANN] Grace đź’…, fancy diagnostics library for compilers , with no external dependencies. Examples:

image
image1621Ă—559 25.7 KB

image
image1617Ă—400 26.2 KB

I used AI assistance to translate the Diagnose library: a day to get the ~1500-line module translated and compiling, and another half day to get it displaying reasonably. The Haskell original relies on an external library’s layout engine (boxes and wrapping) which I did not translate, so caveat emptor.

Aside: This was my first time using AI (GPT-4.1 in vscode) to write code. I got lucky since it seems that Haskell translation is very good, and the visual end-result of the Diagnose library makes it easy to find and fix problems. Since I very recently did a hand-translation of Haskell into OCaml I can roughly estimate translation went 2-3X faster with AI. But AI seriously messes with my mental flow for non-translation work, so I turned AI off.

If you want to use it, reply back and I’ll promote it to a standalone library and submit it to opam.

Docs: Diagnose (MlFront_Thunk.MlFront_Thunk.Diagnose)

Another single-file module is “FilePath”, which is my small but growing replacement for Stdlib Filename module. The problem I have with Filename.concat in particular is that it is not deterministic and hermetic. I run code on a Windows machine and file paths print a certain way. Then I run the same code on a mac and file paths print differently. Sometimes expect and integration tests break. It gets worse when I generate artifacts meant to be shared reproducibly between machines.

Docs: FilePath (MlFront_Core.MlFront_Core.FilePath)

Again, if you think you’ll use it, I’ll pull it into a standalone library and submit it to opam.

2 Likes
2

And the source code: src · V2_4 · DkML / Build Tools / MlFront · GitLab (MlFront_Thunk/Diagnose.ml and MlFront_Core/FilePath.ml).

3

Very impressive! Especially given the time in which you achieved this! How would you feel about integrating this with Grace as a new renderer backend? This is the direction I was planning to go with Grace (along with removing the dependencies on core, etc).

Aside from some new diagnostic metadata in your Report.ts, the type is very similar to Grace’s diagnostics, so in theory it should work out very nicely.

1 Like
4

I wouldn’t be able to use Grace without removing its dependencies first, and that would use a lot of time I don’t have. But yes, since the types are mostly compatible, I can tweak/refactor the Diagnose module over time so that it becomes easier to merge into the higher-level Grace library.