integrations/haskell/notes/001-garnet.md

# 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.