> Il giorno 11 feb 2022, alle ore 16:42, H. Nikolaus Schaller > <h...@goldelico.com> ha scritto: > > > >> Am 11.02.2022 um 16:36 schrieb Umberto Cerrato <umbertocerr...@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 >>>> <h...@goldelico.com> ha scritto: >>> >>> >>> >>>>> Am 08.02.2022 um 17:38 schrieb Gregory Casamento >>>>> <greg.casame...@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 >