Richard when you said roc glue, did you mean roc docs by any chance?
Richard Feldman said:
come to think of it,
roc glueis already pretty close to this :thinking:
I'm finding this a bit unintuitive, not sure what you mean by an API for a package website being similar to glue code.
one thing I'm starting to realize is that roc glue is actually useful for more things than just generating glue code
so pretend it's named roc gen
instead of roc glue
and what it does is you give it a "generator" .roc file which accepts a list of top-level exposed Roc types (including the doc strings associated with each type) organized by module, and that generator .roc file specifies the contents of the output files that should be generated when you run roc gen
in that world, you can use it for things like:
roc docsIs that just the glue functionality you’ve already planned or implemented? Because that seems… extremely powerful.
Using it to generate Elm types and encoders/decoders seems like it could possibly replace something like GraphQL
“What’s the spec for this endpoint?”
“Just import the module and your editor will tell you”
It doesn't have any of the doc stuff yet, but theoretically you could make it generate the elm types for a roc app. That said, you would have to do a minor workaround because it is really only made to translate host types and not a random other type.
Spec is essentially the roc files here: https://github.com/roc-lang/roc/tree/main/crates/glue/platform
An example use is the rust glue: https://github.com/roc-lang/roc/blob/main/crates/glue/src/RustGlue.roc
maybe we should move the discussion on multi-purpose glue to another thread? both for documentation and because it is interesting enough to continue the debate somewhere else! :)
13 messages were moved here from #ideas > packages website by Anton.
Last updated: Jun 16 2026 at 16:19 UTC