I agree regarding the syntax. Most of differences as compared to ObjC seem to be focused on simply removing characters, increasing ambiguity for the reader, without any adequate justification for their removal.
The ugliness of ObjC has little to do with brackets and semicolons, and a lot to do with the lack of higher-level functional constructs and type-system features.
A language that was ObjC-compatible and yet could succinctly express LINQ/Rx-level type/api complexity would be a genuinely interesting successor to ObjC.
Syntax aside, however, the emergence of ObjC-compatible languages is contributing to the pool of knowledge on how to produce one, provides a set of possibly re-usable code to do so.
[edit] Dug into the code. It looks like the author is actually forking clang outright. This is an interesting approach, as it allows you to swap in a new compiler that supports both your language, and objc, possibly interchangeably.
The way that clang is designed (and as I understand it, I haven't looked in great detail), it's pretty much impossible to use it as a library to backend your own front-end parser/lexer atop -- you have to fork clang itself to inject your own code in.
I'm undecided as to whether tying yourself to clang (instead of the underlying llvm) is a net win for an alternative language implementation. Thoughts?
The ugliness of ObjC has little to do with brackets and semicolons, and a lot to do with the lack of higher-level functional constructs and type-system features.
A language that was ObjC-compatible and yet could succinctly express LINQ/Rx-level type/api complexity would be a genuinely interesting successor to ObjC.
Syntax aside, however, the emergence of ObjC-compatible languages is contributing to the pool of knowledge on how to produce one, provides a set of possibly re-usable code to do so.
[edit] Dug into the code. It looks like the author is actually forking clang outright. This is an interesting approach, as it allows you to swap in a new compiler that supports both your language, and objc, possibly interchangeably.
The way that clang is designed (and as I understand it, I haven't looked in great detail), it's pretty much impossible to use it as a library to backend your own front-end parser/lexer atop -- you have to fork clang itself to inject your own code in.
I'm undecided as to whether tying yourself to clang (instead of the underlying llvm) is a net win for an alternative language implementation. Thoughts?