3 ms·

Having a compatibility layer with C doesn't impact your language design, and depending on how 'complete' you want that compatibility it doesn't have to be a lot

by veltas 4y ago

Having a compatibility layer with C doesn't impact your language design, and depending on how 'complete' you want that compatibility it doesn't have to be a lot of effort. Interestingly I think all high-level languages have had to deal with this, I don't think it's new. The very old FORTRAN manuals would all describe how to include assembly functions. Lots of old C content would explain how to use Fortran functions with your work, or how to use C with different system languages for mainframes.

Someone 4y ago
Looking at the complete programming language landscape, Fortran, C, and assembly are relatively similar. If you have garbage collection (more so for GC that moves objects around), lazy sequences, strings that aren’t byte sequences terminated by zeroes, etc. your C compatibility layer will have warts. If you really need to call C, and want that to be performant, that may limit your design options. Python is a clear example.
- veltas 4y ago
  That issue applies to anything 'managed', and applies between managed languages as well (actually more so, have fun interfacing between two different GC systems). The compatibility layer can be a bit warty, but does it matter? We just want the ability to use libraries/interfaces we find useful. I don't think this is unique to C, and frankly I think C has some of the easier ABIs to get basic interfacing with. What language can't talk in arrays and numbers?
  - Someone 4y ago
    Numbers aren’t as easy as one would think because of the size of integers and endianness. Also, some languages need to convert their dynamically sized integers to 32- or 64-bit C integers. For arrays, multi-dimensional ones are tricky, as is returning them from calls. And then, there’s structure, with C’s insistence that fields in a structure get stored in declaration order and structure padding.

by veltas 4y ago

Someone 4y ago

Looking at the complete programming language landscape, Fortran, C, and assembly are relatively similar. If you have garbage collection (more so for GC that moves objects around), lazy sequences, strings that aren’t byte sequences terminated by zeroes, etc. your C compatibility layer will have warts. If you really need to call C, and want that to be performant, that may limit your design options. Python is a clear example.

veltas 4y ago
That issue applies to anything 'managed', and applies between managed languages as well (actually more so, have fun interfacing between two different GC systems). The compatibility layer can be a bit warty, but does it matter? We just want the ability to use libraries/interfaces we find useful. I don't think this is unique to C, and frankly I think C has some of the easier ABIs to get basic interfacing with. What language can't talk in arrays and numbers?
- Someone 4y ago
  Numbers aren’t as easy as one would think because of the size of integers and endianness. Also, some languages need to convert their dynamically sized integers to 32- or 64-bit C integers. For arrays, multi-dimensional ones are tricky, as is returning them from calls. And then, there’s structure, with C’s insistence that fields in a structure get stored in declaration order and structure padding.