Re: GCC and Clang

[Umberto Cerrato]

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

ok.

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

thank you for the link.

> 
> 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.

yes

> 
>> 
>> 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
>