5 ms·

I wish them the best, but getting two of the most complicated languages available today with widely different semantics talking to each other is going to be a t

I wish them the best, but getting two of the most complicated languages available today with widely different semantics talking to each other is going to be a tall order. I wish they'd start by standardizing something equivalent to "extern C" in Swift, so other languages can consume (wrapped) Swift libraries without having to implement support for the rather complicated Swift ABI.

estebank 5y ago
I think there's space for a high-level ABI that specifies little more than C + VTables + callback register (and optionally ownership information, even if ignored by the caller or host) that multiple languages could decide to use for interop. COM already exists and its a shame that it simultaneously does too much and too little to aid in safely exposing APIs, but I would love to see its ideas pushed further.
- sirwhinesalot 5y ago
  I've discussed a similar concern in another hackernews post, though there I suggested improvements to the C language itself since it's the one standard everyone is somewhat forced to follow. The problem with such an ABI is getting people to use it, there's no single entity with enough power to enforce it. I've thought of tackling the problem in another direction, making a simple C-like language (but slightly higher level) which uses the C ABI but with proper support for slices/strings/interfaces/errors/etc. and automatically produces wrapper code for mainstream languages (C++, Java, C#, Swift). The wrappers wouldn't be idiomatic code in the host language, but they'd be directly usable, whereas right now wrapping a "C" library (even when produced by a higher level language) requires recovering all of the semantic information in an additional, library-dependent high-level wrapper. For example, some SMT solvers expose quite nice C APIs, but to use them in say... Python, you'd need to use ctypes and a lot of low level code, which is why they go out of their way to expose wrapper APIs. Some solvers like Yices2 have really low level Python wrappers, which mostly take care of the memory management, unpacking lists into a pointer and a length, and string conversions. There's no reason that couldn't be automated with a slightly higher-level than C language.
  - estebank 5y ago
    Focusing on the "you have now N + 1 standards" problem, I think following the Language Server strategy is the way to go: you don't force people to support it, you focus on specifying an API that support a handful of representative bridges (let's say Python <-> Swift <-> Java <-> Haskell), with a builtin method to evolve and then let people realize that supporting this new ABI immediately brings support for every other language that supports it in an idiomatic-ish way.
    - sirwhinesalot 5y ago
      Yes, the wrapper generators would not be built into the compiler, they're just little pieces of software that generate the relevant code (anyone could develop one in their own language in a couple of days). The language exists merely as a way of directly interfacing with the ABI, a way to get the libraries out the door so interest in the ABI exists (same as how VSCode made LSP popular). The problem with doing Python <-> Swift is that you cannot (and should not) try to expose the entirety of Python and Swift to either side. So you need an "extern ABI" solution to expose your Swift code, except this is not built in to the Swift compiler so now you are in trouble. If you go the external route you end up with SWIG, which is something you only use when you have no other option (CVC4 moved away from it for example). Having a language that directly supports the ABI sidesteps this issue. All code written in the language works with the ABI directly so you get the wrappers for free without thinking about how to implement them. A lot of libraries are written in C directly for this very reason! Once it becomes popular enough, languages would implement "extern ABI" directly, and can now talk to each other over it without the middleman. Same as how a compiler with LSP support can be used in editors that are not VSCode.
  - pjmlp 5y ago
    > The problem with such an ABI is getting people to use it, there's no single entity with enough power to enforce it. There is on Apple (XPC), Microsoft (COM/UWP) and Google (JNI, Android IPC, Fuchsia IDL), IBM (TIMI / Language Environments). The problem are UNIX FOSS clones that lack such overlords.
    - 5y ago
favorited 5y ago
> I wish they'd start by standardizing something equivalent to "extern C" in Swift There is the unofficial (but very relied upon) @_cdecl, if you're OK with needing to update your code if/when that eventually gets standardized. That attribute will take care of the calling convention difference for you. https://github.com/apple/swift/blob/main/docs/ReferenceGuides/UnderscoredAttributes.md#user-content-_cdeclcname https://github.com/apple/swift/blob/main/docs/ReferenceGuide...
- sirwhinesalot 5y ago
  I'm aware, but it's still unofficial and I've been burned by depending on such things before. Hopefully it'll become official soon.

estebank 5y ago

I think there's space for a high-level ABI that specifies little more than C + VTables + callback register (and optionally ownership information, even if ignored by the caller or host) that multiple languages could decide to use for interop. COM already exists and its a shame that it simultaneously does too much and too little to aid in safely exposing APIs, but I would love to see its ideas pushed further.

sirwhinesalot 5y ago
I've discussed a similar concern in another hackernews post, though there I suggested improvements to the C language itself since it's the one standard everyone is somewhat forced to follow. The problem with such an ABI is getting people to use it, there's no single entity with enough power to enforce it. I've thought of tackling the problem in another direction, making a simple C-like language (but slightly higher level) which uses the C ABI but with proper support for slices/strings/interfaces/errors/etc. and automatically produces wrapper code for mainstream languages (C++, Java, C#, Swift). The wrappers wouldn't be idiomatic code in the host language, but they'd be directly usable, whereas right now wrapping a "C" library (even when produced by a higher level language) requires recovering all of the semantic information in an additional, library-dependent high-level wrapper. For example, some SMT solvers expose quite nice C APIs, but to use them in say... Python, you'd need to use ctypes and a lot of low level code, which is why they go out of their way to expose wrapper APIs. Some solvers like Yices2 have really low level Python wrappers, which mostly take care of the memory management, unpacking lists into a pointer and a length, and string conversions. There's no reason that couldn't be automated with a slightly higher-level than C language.
- estebank 5y ago
  Focusing on the "you have now N + 1 standards" problem, I think following the Language Server strategy is the way to go: you don't force people to support it, you focus on specifying an API that support a handful of representative bridges (let's say Python <-> Swift <-> Java <-> Haskell), with a builtin method to evolve and then let people realize that supporting this new ABI immediately brings support for every other language that supports it in an idiomatic-ish way.
  - sirwhinesalot 5y ago
    Yes, the wrapper generators would not be built into the compiler, they're just little pieces of software that generate the relevant code (anyone could develop one in their own language in a couple of days). The language exists merely as a way of directly interfacing with the ABI, a way to get the libraries out the door so interest in the ABI exists (same as how VSCode made LSP popular). The problem with doing Python <-> Swift is that you cannot (and should not) try to expose the entirety of Python and Swift to either side. So you need an "extern ABI" solution to expose your Swift code, except this is not built in to the Swift compiler so now you are in trouble. If you go the external route you end up with SWIG, which is something you only use when you have no other option (CVC4 moved away from it for example). Having a language that directly supports the ABI sidesteps this issue. All code written in the language works with the ABI directly so you get the wrappers for free without thinking about how to implement them. A lot of libraries are written in C directly for this very reason! Once it becomes popular enough, languages would implement "extern ABI" directly, and can now talk to each other over it without the middleman. Same as how a compiler with LSP support can be used in editors that are not VSCode.
- pjmlp 5y ago
  > The problem with such an ABI is getting people to use it, there's no single entity with enough power to enforce it. There is on Apple (XPC), Microsoft (COM/UWP) and Google (JNI, Android IPC, Fuchsia IDL), IBM (TIMI / Language Environments). The problem are UNIX FOSS clones that lack such overlords.
  - 5y ago

favorited 5y ago

> I wish they'd start by standardizing something equivalent to "extern C" in Swift There is the unofficial (but very relied upon) @_cdecl, if you're OK with needing to update your code if/when that eventually gets standardized. That attribute will take care of the calling convention difference for you. https://github.com/apple/swift/blob/main/docs/ReferenceGuides/UnderscoredAttributes.md#user-content-_cdeclcname https://github.com/apple/swift/blob/main/docs/ReferenceGuide...

sirwhinesalot 5y ago
I'm aware, but it's still unofficial and I've been burned by depending on such things before. Hopefully it'll become official soon.