Conversation

This is a future I want to see โ€“ an ABI where types are preserved:
Quote Tweet
Fifth: The ABI should include the ability to encode information about types and layouts, not just function names. This should be used at compile/runtime to provide type information. Compilers should be able to import ABI libraries directly, or provide codegen tools to get headers
Show this thread
1
5
The quoted proposal seems a lot like a reinvention of RPC. However most RPC systems today have fairly weak ad-hoc type systems.
1
Yeah, it's pretty similar. I'm guessing this would match a wishlist of a nice RPC thing pretty closely. It's also definitely not a new idea - see some of the things I linked here:
Quote Tweet
Replying to @bitshiftmask
Regarding typed ABIs, have you seen the work on type preserving compilation and linking types? Would be cool to look into this stuff: eg. not sure how up to date this is, but there's interesting stuff here: silc.ccs.neu.edu/projects/ (@aatxe linked me to this ages ago).
1
1
Mesa also preserved types until link time I think? I'm not sure if it was present in the ABI though, and I doubt it would have everything on the wishlist, like the versioning stuff (I'm no expert on that history though).
1
2
Replying to
Well put another way a synchronous zero-copy shared-memory RPC is effectively also a kind of ABI. The focus on ABI is a bit confusing to me though, couldn't you use the system ABI with added entry point metadata?
1
1
Shipping libraries with extra files that contain type and version metadata makes sense, you just need your format to catch on. GObject introspection is pretty well established
1
2
Show replies