Comment by sylware | Hacker News Reader

Comment by sylware | Hacker News Reader

Parent Full thread

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?

What'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");

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

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

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

Having to create a function where a simple expression would suffice is "typing in mittens" programming...

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

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

I would say that languages where "if" can be used as expression provide a different (perhaps better) syntax for the same ternary operator.

    a = if x then y else z

is just a more verbose version of

     a = x ? y : z;

Raku uses yet another form of the same operator:

     a = x ?? y :: z;

Syntactic sugar :-)

It's actually

    a = x ?? y !! z

And that's because a single : is used for many other semantics in the Raku Programming Language. And ?? and !! standout better in code.

https://docs.raku.org/language/operators#infix_??_!!

You are right, of course. Sorry! "Colon belongs to Larry" :-)

I think I made this mistake because :: was used in one of the drafts for Perl 6, but the final specification uses !!

Sorry for the confusion, but you did indeed decipher my meaning (if-statements)! I agree that if-expressions are far more readable in languages that support them (Python and Haskell come to mind for me), even though they're arguably just syntactic sugar for the ternary operator.

Chained ternaries are quite readable when formatted as tables...

    a = (x < 5 ) ? 'LESS'
      : (x > 5 ) ? 'MORE'
      :            'SAME';

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

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

What you mean by "breaking inside"? You cannot nest ternaries, but you can chain them (see my other comment above).

I like the ternary too but to pretend that it's ok because it's useful in perl is more of a counter argument...

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

> Namely it is easier to write a naive rust compiler than a C compiler?

You must be joking.

That's a question.

You know the answer?

Writing a Rust lexer/parser, maybe. The entire compiler? Dubious.

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

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

Easier to write a rust compiler than a C compiler? I must be somehow misinterpreting this.

It is a question.

Reply on news.ycombinator.com