4 ms·
Even C has already a syntax way too rich and complex (and C11 and C17 tantrums are making things worse). Integer promotion should go, like implicit cast for an
by sylware 3y ago
Even C has already a syntax way too rich and complex (and C11 and C17 tantrums are making things worse).
Integer promotion should go, like implicit cast for anything except void* and literals, but we are missing a dynamic/static casts syntax explicit split.
Only one loop keyword, loop {}, no switch, no anonymous block, no "a?b:c" operator. typedef has to go, (and typeof,generic,etc), the variable arguments of preprocessor function should be defined once and for all. __thread must go as tls should be managed dynamically and explicitely with the system interface, never statically and hidden by the runtime.
Only sized primitive types (u8/s8...). That said, anonymous union/struct are very nice for complex memory layout.
And all the things I am forgetting right now.
With the pre-processor and coding discipline you can get close to that already, but I was told that what I am describing is basically the simplicity of rust syntax, true? Namely it is easier to write a naive rust compiler than a C compiler?
- IlliOnato 3y agoWhat's wrong with ternary operator ("a?b:c") ? It seems many people hate it but I've never seen a reason for it. This operator is very useful and uncontroversial in Perl, it's normal (and quite readable) in selecting a value for assignment. One is expected to use good practices with it, but it is nice. Is the problem the fact that in C you can use it instead of if, selecting not values but actions, like (a > b) ? printf("A") : printf("B");
- zogrodea 3y agoI (a different person replying to your post) don't mind ternary operators, but I do prefer if-expressions which convey the same thing semantically but can be nicer to read (and also way better when chaining else-if ladders - nested ternaries can be a nightmare to read). https://stackoverflow.com/a/46843369 https://stackoverflow.com/a/46843369
- IlliOnato 3y agoChained ternaries are quite readable when formatted as tables... a = (x < 5 ) ? 'LESS' : (x > 5 ) ? 'MORE' : 'SAME';
- 8372049 3y agoTo me personally, the use case for ?: is selecting a value for a const: const value = cond ? a : b; Using an if instead would mean you can't make it const, and is usually more convoluted to read. For pretty much all other use cases, I agree that ifs are better.
- kevindamm 3y agoIn that case you can have the result of a function call be assigned to the const, and the function be the if/else for the value. With a well-named function it can even be more readable than the ternary.
- IlliOnato 3y agoHaving to create a function where a simple expression would suffice is "typing in mittens" programming...
- kevindamm 3y agoFair enough.. I actually use ternary sometimes, especially in brief return statements, and especially when both results are simple values. I only really avoid it when the result expressions are multiline. I just felt like pointing out the obvious when I saw GP's comment.
- zogrodea 3y agoI was confused by your reply when I first read it (didn't quite understand it), but I think it comes from a miscommunication when I had intended if-expressions (if statements that return a value) while you had if-statements in mind. For example, the following F# code (you can run `dotnet fsi` in a terminal to try it out, if you have dotnet installed) is equivalent to a ternary expression: // the value of x is "is_not_lower" after evaluation (x is a constant/immutable value, just like a 'const' value in JS) let x = if 0 > 1 then "is_lower" else "is_not_lower" Which is equivalent to the following (in JS): const x = 0 > 1 ? "is_lower" : "is_not_lower" In F# (and also Kotlin which I linked before), you can have clean code with if-elif-else ladders while the equivalent (using nested ternaries) would be hard to read. For example: // the constant/immutable variable "comparison" is either "HIGHER", "LOWER" or "EQUAL" depending on the branch taken let comparison = if a > b then "HIGHER" elif a < b then "LOWER" else "EQUAL" In JS land (and also most common programming languages which have plain if-statements), I agree a ternary would often be preferrable as long as it's not nested.
- dgfitz 3y agoI don’t like them because they’re easy to write and a pain to deal with later. My biggest irritation comes when I’d like to break inside the if or else clause of a ternary and can’t. There is also more mental overhead to parse and keep in the mental stack. I have also seen them used cleanly and beautifully, but that is a rare occurrence.
- sylware 3y agoSomething which is significantly "controversial", or has no significant and pertinent impact, should not increase the compiler technical cost. Syntax sugar is the enemy of compiler technical costs. For instance, a "feature" of significant and pertinent impact missing, in the list I provided, load and store from unaligned memory address should have their own keywords as this is really important, even though modern hardware micro-archs tolerate that at a cost. Anybody using that abomination of "struct packing" C extensions should think again: C has been meant for aligned access by default, namely unaligned access should be at a syntax cost, and should pop up from the syntax and be HARDCORE explicit. I don't even think rust syntax is that clean, am I wrong? (hopefully) For instance in linux printf, I did run in a beautiful (irony) "aligned" attribute on a stack variable. I was reading the code and I though there was a bug since I did not read the variable declaration as I was very mistaken that the variable name was enough... Yeah, should be banned from the kernel (hopefully, rust is careful to avoid that abomination in its syntax). When I have "packed" data structures, I am, usually, careful at having everything "byte" defined and use explicit macros for Xword loads and stores. "Letting the compiler do that for you" is dual edge sword. And I don't even start on the _Generic abomination, which creates so much type indirection you don't know what you are dealing with unless you read a ton more code.
- IlliOnato 3y agoWhat you mean by "breaking inside"? You cannot nest ternaries, but you can chain them (see my other comment above).
- speed_spread 3y agoI like the ternary too but to pretend that it's ok because it's useful in perl is more of a counter argument...
- IlliOnato 3y agoA was not using Perl as an argument, I am just much more familiar with Perl than C, so I wondered if the ternary operator works differently in C than in Perl, making it more problematic/less useful.
- lelanthran 3y ago> Namely it is easier to write a naive rust compiler than a C compiler? You must be joking.
- sylware 3y agoThat's a question. You know the answer?
- vacuity 3y agoWriting a Rust lexer/parser, maybe. The entire compiler? Dubious.
- sylware 3y ago"maybe", then you don't know if it is easier to write a rust naive compiler than a C naive compiler (look at tinycc, cproc/qbe, simple-cc/qbe, etc).
- vacuity 3y agoYou don't seem to be asking a question anymore. That's not what I said maybe to, anyways. If both languages have grammars that are on the same level, I don't see why someone experienced in writing a lexer/parser would have more difficulty with one. I think Rust only needs lookahead for raw strings and there are some quirks with C's grammar, but I'm not knowledgeable about that.
- cellularmitosis 3y agoEasier to write a rust compiler than a C compiler? I must be somehow misinterpreting this.
- sylware 3y agoIt is a question.