59 lines
2.6 KiB
Markdown
59 lines
2.6 KiB
Markdown
# Garnet Findings
|
|
|
|
Date: 2026-03-24
|
|
Path inspected: `./tmp/garnet`
|
|
|
|
## Summary
|
|
|
|
`./tmp/garnet` is a proof-of-concept for Rust/Haskell interop.
|
|
|
|
The repo is testing a specific pipeline:
|
|
|
|
Rust exports a C ABI -> `cbindgen` emits a header -> `hs-bindgen` produces Haskell bindings -> hand-written Haskell wrappers clean up the API.
|
|
|
|
It succeeds as a demo. It does not read as production-ready infrastructure.
|
|
|
|
## What It Contains
|
|
|
|
- `./tmp/garnet/rust/lib.rs` - Rust FFI examples: strings, structs, enums, arithmetic, recursive trees.
|
|
- `./tmp/garnet/rust/build.rs` - header generation plus a local patch for `hs-bindgen` compatibility.
|
|
- `./tmp/garnet/lib/GarnetRs/Raw.hs` - low-level binding generation from the generated header.
|
|
- `./tmp/garnet/lib/GarnetRs/Wrapped.hs` - Haskell-facing wrapper types and conversions.
|
|
- `./tmp/garnet/exe/Main.hs` - demo executable that exercises the bridge.
|
|
- `./tmp/garnet/build` - custom build glue for Cargo and Cabal.
|
|
|
|
## Review
|
|
|
|
The project makes the intended architecture clear. Separating raw bindings from the wrapper layer is the right call, and the examples are broad enough
|
|
to be useful. This is more than a toy "add two numbers" demo.
|
|
|
|
That said, the repo still looks early. The build is custom, the dependency stack is pinned to git revisions, and the Rust build script contains a
|
|
workaround for upstream tooling issues. That combination is acceptable in an experiment, but it is a weak base for a maintained integration layer.
|
|
|
|
The biggest limitation is that code generation does not remove the hard part. The Haskell side still needs manual wrapper code to turn raw bindings
|
|
into something ergonomic. The repo proves that the pipeline works, but it also shows that the pipeline is not yet cheap.
|
|
|
|
## Pros
|
|
|
|
- The architecture is clean enough to follow.
|
|
- The examples cover realistic FFI shapes, not just trivial functions.
|
|
- The split between generated and hand-written code is sensible.
|
|
- The repo is small enough to serve as a reference implementation.
|
|
|
|
## Cons
|
|
|
|
- The build flow is manual and brittle.
|
|
- The setup depends on alpha-stage or pinned upstream tooling.
|
|
- The local header patch is a red flag for maintainability.
|
|
- The wrapper layer still carries noticeable manual boilerplate.
|
|
- There is no obvious sign of tests, CI, or a long-term stability plan.
|
|
|
|
## Status
|
|
|
|
Current status: working prototype.
|
|
|
|
It appears far enough along to prove the interop path and demonstrate the tooling choices. It does not appear far enough along to support repeated
|
|
reuse without more work on build integration, test coverage, and dependency stability.
|
|
|
|
In reviewer terms: promising experiment, useful reference, not ready to trust as infrastructure.
|