discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GCC and Clang


From: H. Nikolaus Schaller
Subject: Re: GCC and Clang
Date: Fri, 11 Feb 2022 15:54:06 +0100


> Am 08.02.2022 um 17:38 schrieb Gregory Casamento <greg.casamento@gmail.com>:
> 
> The way I see it, we have two ways we can go.

Usually there is a third...

> In each, I have outlined what I believe needs to be done.  It may or may not 
> be complete:

> GCC
> 1) Implement syntactic sugar 
>    a) This includes @[], @{}, and @autorelease as well as
>    b) Various @property directives
>    c) Improvements to the GCC libobjc to support the new syntax
>       i) Implementation of ARC in the runtime

What about a preprocessor for gcc to add the missing syntactic sugar?

It may be much easier to maintain than digging into gcc source code.

BTW: this is the same method as ObjC did come to our world.
Brad Cox wrote a preprocessor for C...

It was NeXT who integrated ObjC syntax into gcc, according to
https://news.ycombinator.com/item?id=11639658

IMHO we should start to think more in modular vs. monolithic approaches,
especially as computing power has increased and developer's time
is limited. Splitting into preprocessor and compiler would be such
a modularization. Costs some processor time but saves developer's time.

Of course there are limitations to what a simple preprocessor
can do (e.g. it needs quite a lot of logic in the AST to track data
types of symbols), but as far as I see especially @[], @{}, and @autorelease
should not be extremely difficult. They are more or less macros that
can be expanded.

ARC is a different topic. But I think it can also be done by a
preprocessor. If a full compiler can determine when to add retain/release
from static syntax analysis, a preprocessor can as well. Again provided
that it has a grammer and builds an abstract syntax tree. Well, such
a preprocessor is sort of a fragment of a fully fledged compiler. It is
lacking code optimization rules, memory and register allocation, ABI
compatible assembler output, helper libraries etc.

In other words: it lacks all problems which we have with LLVM/Clang and
gcc.

Generally this would give objc programmers a solution and gcc developers
time to fully integrate such features (and then the preprocessor
becomes a simple "cat <input | gcc" command...).

What I don't know is how attractive this is. Well, I have code for an
ObjC processor [1] which is a good basis but it appears as if nobody
wants to jump on this idea and help to develop it.

just my 2cts, Nikolaus

[1]: https://github.com/goldelico/mySTEP/tree/master/ObjC


reply via email to

[Prev in Thread] Current Thread [Next in Thread]