[Openmcl-devel] M1 port: Call for funding

[Chris Hanson]

I’m not rme, but I think these are interesting questions worth discussing.

On Dec 29, 2023, at 10:29 AM, Ron Garret <ron at flownet.com> wrote:
> 
> 6.  One of the things that makes CCL what it is is the ObjC bridge and the IDE.  Would it be reasonable to consider porting those to SBCL?  Or are they intimately bound to the CCL architecture?

I think the bridge itself may be somewhat tied to CCL’s FFI implementation, but I think the IDE’s main dependency (from that perspective) is the bridge.

One thing that would be useful to any sort of bridge is the ability to handle all of Apple’s extra annotations when groveling headers, to do things like distinguish enums-as-set-elements versus enums-as-bit-fields, to indicate nullability, to type-constrain collection elements, and so on, to improve the import into Swift. (E.g. whether a C enum is imported as a Swift enum with cases or a Swift struct with static members, and what its underlying type in the ABI should be.)

I do think that the CCL core language should probably be treated as a separate "project” than the bridge which should similarly be a separate “project” from the IDE. I suspect people would find them less intimidating to pick up and hack on if they weren’t all in the same repo, simply because their scope and boundaries would be more obvious to the uninitiated.

> 7.  What is your reading of the tea leaves with regards to the future of ObjC on the Mac platform?  Is it even worth bothering trying to port the ObjC bridge, or should we be thinking about a Swift bridge instead?

I don’t speak for Apple, but speaking generally, if Apple deprecates a technology or API it usually stays around until something like a major architecture change, and often even beyond that, so everything built against it in the past can still run. (I believe OpenGL is still available on Apple Silicon, for example.) And that’s when things are *deprecated*, which Objective-C isn’t. However, more frameworks and APIs in new OSes are only available from Swift, so it’s quite worth looking at how to accommodate those whether via a bridge or via FFI.

That doesn’t mean it wouldn’t be worthwhile to start looking into a Swift bridge. For anyone who has an interest in that, I’d strongly suggest looking at not just how Swift interoperates with Objective-C, but how Chris Lattner’s team at Google added certain types of dynamic lookup to the language for Swift Tensorflow, and how the bidirectional Swift-C++ bridging is being implemented as well as its constraints. <https://www.swift.org/documentation/cxx-interop/status/>

  — Chris