Richard Feldman (Nov 18 2021 at 16:17): Richard Feldman (Nov 18 2021 at 16:17):so right now if I'm working on a Roc platform and I send a record to a host, like { foo : Str, bar : U16, baz : List Str } on the host side I need to manually write out a type definition in my systems language that corresponds to it, e.g. in Rust, struct { baz: RocList<RocStr>, foo: RocStr, bar: u16 }
Richard Feldman (Nov 18 2021 at 16:18):on the systems side, order matters, but on the Roc side it doesn't; there's an algorithm to translate between them (sort fields by alignment and then alphabetically) but it's easy to mess this up if you have a substantially-sized record
Richard Feldman (Nov 18 2021 at 16:19):similarly, for tag unions you have to know where the discriminant goes and put it in the right place etc
Richard Feldman (Nov 18 2021 at 16:20):so I've been thinking for a long time (literally years!) that we should have a way for the Roc compiler to spit out the layouts of the types that the host needs
Richard Feldman (Nov 18 2021 at 16:21):one open question is: should we make a language-agnostic format so that people can make separate language-specific type generators (e.g. one for Rust, one for Zig, one for C, C++, Swift, etc...) or try to bake in first-class support for specific languages?
Richard Feldman (Nov 18 2021 at 16:22):obviously the "first-class support for specific languages" is more convenient, e.g. I run one roc CLI command and get a .rs file, yay!
Richard Feldman (Nov 18 2021 at 16:24):but there are various long-term maintenance downsides, especially around having to keep up with other languages' new releases (which may have syntax changes etc - e.g. today we'd target Rust 2018, but next year we'd presumably want to target Rust 2021 - should we support both in the Roc compiler indefinitely, for backwards compatibility? If so, then the roc executable gets bigger and bigger forever based on other languages' design decisions)
Richard Feldman (Nov 18 2021 at 16:25):so based on that I'm leaning towards the "emit some language-agnostic description of the layouts, and then let people write language-specific converters for whatever languages they want" design
Richard Feldman (Nov 18 2021 at 16:25):anyone have thoughts on this?
Brendan Hansknecht (Nov 18 2021 at 16:42):I think most users of systems languages just want/need a spec. So telling them the pieces, their order, their alignment, and bitcount should be just fine. so i would vote for agnostic. Going from agnostic should be easy for a user and someone else can maintain a generator for specific languages if wanted
Lucas Rosa (Nov 18 2021 at 17:37):Yea I agree with Brendan, less work for us and more "pluggable" for everyone else
Lucas Rosa (Nov 18 2021 at 17:38):maybe some thought should go into a good format to spit this stuff out to, something easy to parse would be nice
Brian Carroll (Nov 18 2021 at 19:45):I imagine that the developer of a particular host is gradually adding features and fields one at a time. Behind every field is presumably a lot of domain specific code that understands what the field means, and that code takes a few days or weeks to write.
Fixing the order of fields sounds like a few minutes of debugging. Not a big deal. A debug printing function that prints in the right order would be perfect.
The code generator idea sounds suitable for some much more fast paced scenario, where you're churning stuff out at a high rate. What's the use case there?
Joshua Warner (Nov 18 2021 at 19:47):Fixing the order of fields sounds like a few minutes of debugging. Not a big deal.
If the host interface is narrow, great. If it grows (as most interfaces do), and it grows large enough, then this can become a serious drag on productivity. At work, we have a product that needs to interface with system libraries, to the tune of 100+ unique APIs. If there were a bug in _one_ of those where two arguments were swapped or something, good luck being able to reliably debug that.
Joshua Warner (Nov 18 2021 at 19:49):Debugging FFI interfaces is very persnickety, leads to very bizarre bugs, and any effort we can put into making that easier to do reliably will probably pay itself back 10x, even just talking about with "official" roc hosts.
Richard Feldman (Nov 18 2021 at 20:06):yeah @Brian Hicks and I had one with like 4 fields, and it took us several minutes just to realize that field ordering was the problem because the symptoms were that we were seeing memory garbage in a different struct :sweat_smile:
Brendan Hansknecht (Nov 18 2021 at 20:53):Not saying this is a good interface to target, but for me, seeing the C struct form would be perfect. Gives me all the information I need.
Brendan Hansknecht (Nov 18 2021 at 20:54):So like printing out the roc-host interface with the equivalent C types (or information in a different form) would be perfect for me. Don't really care about code gen. Could be nice for some automated tools, but I don't think it would be a big deal either way.
Brian Carroll (Nov 18 2021 at 22:41):The drawback of C format is that the alignment is implicit rather than explicit. Not everyone uses C or C++ regularly.
Brian Carroll (Nov 18 2021 at 22:43):But some plain text format that can be parsed from most languages.... this is going to end up being JSON, isn't it :laughing:
Brendan Hansknecht (Nov 18 2021 at 22:43):Probably
Lucas Rosa (Nov 18 2021 at 22:44):https://github.com/gruebite/zzz
Zeljko Nesic (Nov 19 2021 at 01:37):This calls for another "standard" format! https://xkcd.com/927/
Lawrence Job (Nov 19 2021 at 21:30):Just thinking out loud, for the purpose of playing devil's advocate - is there a case for building a platform called 'roc-types-generator' and allow people to build applications for this platform that the Roc CLI can employ to generate types? That way, Roc can be completely unopinionated.
The alternative is, as proposed above, one new spec and one generic code generator that can take the spec -- if there are only 5 active languages (keeping in mind the limitations of LLVM and the size of the userbase), and they're unlikely to change, it might be easier to make 5 specialist code-generators than 1 generic one and design a whole standard?
...and if demand changes, the community can add more of these as they see fit.
Last updated: Jun 16 2026 at 16:19 UTC