4 ms·

C syntax is already way too rich and complex, not to mention the bazillions of gcc extensions required to compile the linux kernel. Namely, if it has to be "re

C syntax is already way too rich and complex, not to mention the bazillions of gcc extensions required to compile the linux kernel. Namely, if it has to be "replaced", that would be with something with a much simpler syntax, which will require a bit more of finger power. We don't want to find ourself locked-in by very few compiler vendors (open source or not), that only because it is not reasonable to code a real-life alternative with a small team of averagely skilled devs in a reasonable amount of time. This language should build on C though: no enum/typedef/_generic/switch/etc, only 1 loop keyword (loop{}) only explicit sized types, no integer promotion, no implicit casts (except maybe void* pointers but number literal casts should be) but explicit casts (compile-time and runtime, without that horrible c++ syntax), explicit compile-time const (we have only runtime consts which could be optimized as compile-time consts), enforce extern for functions (and don't try to put the binary format, elf/coff/etc, semantics into the language syntax or worse, the OS interface semantics), etc. With enough discipline (and compiler warnings), we could get close to such language. I did not check the latest and greatest rust syntax, but is what's above its explicit goals? That said, I am a "everything in 64bits RISC-V assembly with x86_64/arm64 legacy ports kind of guy"... if RISC-V is successful (I wish). We could think of high-level language interpreters (coded in assembly, for instance a RISC-V coded python/lua/javascript/etc interpreters).

tristanbvk 4y ago
These are good ideas. The simplicity here is what I am going for.
- sylware 4y ago
  On the long run, it all depends on syntax stability which is tightly coupled with its complexity. The "benchmark" to run to evaluate syntax complexity toxicity, for a compiled language, is how long an alternative compiler written by a small teams of averagely skilled devs, or even one individual averagely skilled dev, can stay a "real life" "working" alternative. Mid-term/long-term planned obsolescence of computer language syntax is really... Oh, and in my previous post: for compile time constants we can use static consts, my bad.
flohofwoe 4y ago
TBH that sounds a lot like Zig (it has two loop keywords though: for and while, but those are for different use cases - for is only for iterating over ranges, and while is the 'vanilla loop' for everything else). Zig does introduce a bit of syntax pollution for its comptime features though (mainly the 'inline' variants of existing keywords), and it adds some syntax sugar for the builtin error handling and optionals - so it's essentially a dismantled C which is then slightly extended into a different direction.
- sylware 4y ago
  This is one too many loop keyword. And something must be done about breaking changes of the syntax (or any never ending "features" additions). We all know that some syntaxic constructs will be nasty in the end and will reasonably need fixing (basically, to keep them excrusiatingly simple from a compiler writing point of view). I am thinking about something like "syntax breakage provisions" from the language authors: for instance, no more than 4 iterations of major syntax breakages, then the language syntax will be frozen for forever. Whatever, I am a everything in assembly kind of guy (with high-level language interpreters written themselves in assembly). All that is a thought experiment for me, nothing more.
timbit42 4y ago
Doesn't Modula-2, Oberon or Ada fill your checkboxes?

tristanbvk 4y ago

These are good ideas. The simplicity here is what I am going for.

sylware 4y ago
On the long run, it all depends on syntax stability which is tightly coupled with its complexity. The "benchmark" to run to evaluate syntax complexity toxicity, for a compiled language, is how long an alternative compiler written by a small teams of averagely skilled devs, or even one individual averagely skilled dev, can stay a "real life" "working" alternative. Mid-term/long-term planned obsolescence of computer language syntax is really... Oh, and in my previous post: for compile time constants we can use static consts, my bad.

flohofwoe 4y ago

TBH that sounds a lot like Zig (it has two loop keywords though: for and while, but those are for different use cases - for is only for iterating over ranges, and while is the 'vanilla loop' for everything else). Zig does introduce a bit of syntax pollution for its comptime features though (mainly the 'inline' variants of existing keywords), and it adds some syntax sugar for the builtin error handling and optionals - so it's essentially a dismantled C which is then slightly extended into a different direction.

sylware 4y ago
This is one too many loop keyword. And something must be done about breaking changes of the syntax (or any never ending "features" additions). We all know that some syntaxic constructs will be nasty in the end and will reasonably need fixing (basically, to keep them excrusiatingly simple from a compiler writing point of view). I am thinking about something like "syntax breakage provisions" from the language authors: for instance, no more than 4 iterations of major syntax breakages, then the language syntax will be frozen for forever. Whatever, I am a everything in assembly kind of guy (with high-level language interpreters written themselves in assembly). All that is a thought experiment for me, nothing more.

timbit42 4y ago

Doesn't Modula-2, Oberon or Ada fill your checkboxes?