4 ms·

What specific features would you like to see in such a lingua franca ABI replacement? I'm struggling to think of anything that's similiar enough across all lang

What specific features would you like to see in such a lingua franca ABI replacement? I'm struggling to think of anything that's similiar enough across all languages to be relevant. Furthermore, many similiar concepts are implemented completely differently in different languages even if they look very similar to the programmer.

samatman 2y ago
> Furthermore, many similar concepts are implemented completely differently in different languages even if they look very similar to the programmer. This is true to some degree, yes. But all those languages manage to speak C ABI through some sort of extern directive or other. I don't believe that's because the de-facto C ABI for any given platform is the optimal common language, but rather, it's the only thing we can rely upon. I'm not a compiler engineer, just an interested amateur, so any detailed proposal I could offer would be painfully naïve. Getting good results would involve attracting the interest and talent of skilled professionals. I'll start by noting that I'm not proposing a Common Object Model which all languages are expected to target. It's been tried, there's prior art, such a format might even be adequate, but: that's a lot of work, the result is sure to be unsatisfactory, and, most important, language core teams aren't going to do this. The idea here is a better interface, for code which is expected to speak to other code. It might be productive to think of it like protobufs for function calls. Libraries could compile in metadata in a binary format, defining the necessary structure of the stack, and the register discipline, for calling into a particular function. This would require some ability to talk about aggregates, to be able to cover constructs like vtables (where the function pointers themselves would define a binary prototype included with the library). This would include a plain-text intermediate format representing the same data, to make life easier on everyone, but it would nonetheless be possible to link against a version of a system library directly, by extracting this definition language from the object code. This reduces the problem space, from having to find a common object format acceptable to every language, to providing a more enriched surface area which languages could publish for the API of library code. A large part of what makes the de-facto C ABI so sticky is that object code is flying blind: I keep emphasizing de-facto because the ABI is a matter of convention, and there's no good way to vary that convention and also let a linker know that you have. I'm optimistic that something along these lines could be designed, such that systems languages could both produce and consume this format, with managed languages consuming it using the standard FFI adaptation technique. It's likely it would be an improvement on the status quo, where everyone just does what the nearest C compiler does, and hopes not to step on one another's toes in the process.
- gpderetta 2y ago
  I struggle to see what would fit between a C ABI and COM that would be a significant improvement. COM can already be generated via IDLs right?
  - pjmlp 2y ago
    Yes, and the tooling sucks, because WinDev suffers from Stockholm syndrome. After 30 years pushing for COM, if you want a good editing experience fo COM IDL, meaning syntax highlighing, code completion, and integration between generated code and Visual Studio projects, one needs to use 3rd party tools. This in what concerns C++ development, where C++ Builder provides a much better experience. If using Delphi, or .NET, it isn't as bad, but then again, mostly because writing IDL isn't needed other than in specially cases not supported out of the box, usually it is driven by language attributes instead.

samatman 2y ago

> Furthermore, many similar concepts are implemented completely differently in different languages even if they look very similar to the programmer. This is true to some degree, yes. But all those languages manage to speak C ABI through some sort of extern directive or other. I don't believe that's because the de-facto C ABI for any given platform is the optimal common language, but rather, it's the only thing we can rely upon. I'm not a compiler engineer, just an interested amateur, so any detailed proposal I could offer would be painfully naïve. Getting good results would involve attracting the interest and talent of skilled professionals. I'll start by noting that I'm not proposing a Common Object Model which all languages are expected to target. It's been tried, there's prior art, such a format might even be adequate, but: that's a lot of work, the result is sure to be unsatisfactory, and, most important, language core teams aren't going to do this. The idea here is a better interface, for code which is expected to speak to other code. It might be productive to think of it like protobufs for function calls. Libraries could compile in metadata in a binary format, defining the necessary structure of the stack, and the register discipline, for calling into a particular function. This would require some ability to talk about aggregates, to be able to cover constructs like vtables (where the function pointers themselves would define a binary prototype included with the library). This would include a plain-text intermediate format representing the same data, to make life easier on everyone, but it would nonetheless be possible to link against a version of a system library directly, by extracting this definition language from the object code. This reduces the problem space, from having to find a common object format acceptable to every language, to providing a more enriched surface area which languages could publish for the API of library code. A large part of what makes the de-facto C ABI so sticky is that object code is flying blind: I keep emphasizing de-facto because the ABI is a matter of convention, and there's no good way to vary that convention and also let a linker know that you have. I'm optimistic that something along these lines could be designed, such that systems languages could both produce and consume this format, with managed languages consuming it using the standard FFI adaptation technique. It's likely it would be an improvement on the status quo, where everyone just does what the nearest C compiler does, and hopes not to step on one another's toes in the process.

gpderetta 2y ago
I struggle to see what would fit between a C ABI and COM that would be a significant improvement. COM can already be generated via IDLs right?
- pjmlp 2y ago
  Yes, and the tooling sucks, because WinDev suffers from Stockholm syndrome. After 30 years pushing for COM, if you want a good editing experience fo COM IDL, meaning syntax highlighing, code completion, and integration between generated code and Visual Studio projects, one needs to use 3rd party tools. This in what concerns C++ development, where C++ Builder provides a much better experience. If using Delphi, or .NET, it isn't as bad, but then again, mostly because writing IDL isn't needed other than in specially cases not supported out of the box, usually it is driven by language attributes instead.