On Tue, Sep 3, 2024 at 7:22 PM Ethan C <[email protected]> wrote:

> Hi everyone,
>
>          Our recent discussion about whether we should switch to a newer
> compiler has brought up an idea I've been thinking about for a while.
> Objective-C was originally implemented as a preprocessor which emitted C
> code.


This is an urban legend. Dr. Cox himself clarified this: it was always a
compiler from the start, it never started as a preprocessor and then
switched.


> C++ was also originally implemented this way (Cfront), and Qt C++
> is still implemented as a preprocessor which emits C++ code. If we could
> make an Objective-C 2.x compiler that emitted C code, we would unlock
> many benefits:
>
> * We could add our own extensions to the Objective-C language rather
> easily (think adding syntax support for traits)
>
> * We could start using Objective-C features which were introduced after
> Objective-C 2.0 without hacky stuff, such as blocks, lightweight
> generics, etc., and allow GNUstep users on GCC-only platforms to use
> these too
>
> * We could support compiler infrastructures other than GCC or LLVM,
> which would mean that it would take less time to get to a working
> GNUstep system when bootstrapping from scratch, and would make it easier
> for us to do things that require C compiler support beyond what standard
> C or GNU C provide
>
> * Our MSVC support would be much easier
>
> * We could switch to libobjc2 for everything, which would give us typed
> selectors and non-fragile ABI even on GCC-only platforms
>

Would this mean internally, still allowing the public facing side to be
pre-ObjC 2.0 compatible? Or would everyone using the GNUstep libs from that
point on be forced into 2.0? 'Cause if it's the latter I can tell you right
now I'm against it, And I'm fairly certain that won't be a popular idea. If
it can aid in the development of the libs in a transparent fashion, where
the end user can choose whichever ObjC dialect they want regardless of what
these use, I got no objections.


> I see a few options to do this:
>
> * We write our own Objective-C-to-C compiler, perhaps using some code
> from autogsdoc and the Objective-S compiler
>
> * We heavily modify Portable Object Compiler (an Objective-C 1.0
> transpiler to C, with its own runtime library) to deal with Objective-C
> 2.0 and libobjc2
>
> * We modify clang's `clang -rewrite-objc` to output standard C rather
> than MSVC C++
>
> Finally, if we want to support compilers other than GCC, Clang, and
> MSVC, I made a list of small C compilers here:
>
> https://github.com/ethanc8/awesome-small-compilers/blob/master/SmallCCompilers.md.
>
> These compilers could be useful to make sure that we're not depending on
> buggy compiler behavior, and to give us a more hackable toolchain with
> which to experiment with. We could also implement C extensions that we
> need much easier than implementing them in GCC or LLVM, if it turns out
> the abilities of GNU C and MSVC C17 or MSVC C++ aren't enough for us.
>
> This seems like a lot of effort, but a lot of the work is already done
> for us. I'm not sure if it will be worth it, but I think it will be,
> since it will make it much easier to evolve the Objective-C language
> forward, support other languages (like Objective-S) which run on top of
> libobjc2, and more.
>
> Does anyone have any thoughts or opinions on this?
>

See my comments above.

Reply via email to