Re: GCC and Clang

[H. Nikolaus Schaller]

> Am 11.02.2022 um 16:36 schrieb Umberto Cerrato <umbertocerrato@outlook.it>:
> 
> wow!
> could that mean it would be easier to install "gnustep"? (and program objc 
> programs?)
> because I was actually asking: is there a more lightweight compiler than 
> those available?

Hm. No. My proposal is to just extend standard gobjc by those "modern" features 
it is lacking.
Not writing e.g. a full ObjC -> C translator and competing with gcc or clang.

BTW: such a full preprocessor did exist long ago (POC = Portable Object 
Compiler):
http://www.sai.msu.su/sal/F/1/POC.html

Unfortuangtely the download links are broken but there may be copies somewhere 
around. 

> 
> by the way I am trying to figure out how to install gnustep...

That is a different story.

> 
> u
> 
>> Il giorno 11 feb 2022, alle ore 16:29, H. Nikolaus Schaller 
>> <hns@goldelico.com> ha scritto:
>> 
>> 
>> 
>>>> 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