Ask HN: A retrofitted C dialect?

It seems people pretty universally dislike type annotations and overly verbose comments, like Ruby's YARD or Java's Javadoc. Also, if your new language doesn't compile with a standard C compiler, kernel usage is probably DOA. That means you want to keep the source code pure C and store additional data in an additional file. That additional file would then contain stuff like pointer type annotations, object lifecycle and lifetime hints, compile-time eval hints, and stuff to make the macros type safe. Ideally, your tool can then use the C code and the sidecar file together to prove that the C code is bug-free and that pointers are handled correctly. That would make your language as safe as Rust to use.

The hardcore C kernel folks can then just look at the C code and be happy. And you and your users use a special IDE to modify the C code and the sidecar file simultaneously, which unlocks all the additional language features. But as soon as you hit save, the editor converts its internal representation back into plain C code. That means, technically, the sidecar file and your IDE are a fancy way of transpiling from whatever you come up with to pure C.

This is true, the Benovolant Dictator model, versus the Rule by committee model problesm.

Committees are notorius for having problems coming to a consensus, because everyone wants to pull in a different direction, often at odds with everyone else.

Benevolent dictators get things done, but it's not necessarily what people want.

And, we live in hope that they stay benevolent.

> Quite don’t understand why these concerns are “concerns” here.

One of the most frustrating things about C is that it is generally taught together with assembly, so that there is a general conflation between C and assembly, as if C is both "just" some sort of portable assembler and the unique language with that property. The main consequence of this is that the C abstract machine [1] tends to be assumed to be the model of how processors work, and this ends up creating a lot of friction where the C abstract machines just doesn't match hardware newer than about 40 years old. It can be a little hard to understand just how bad the friction is if you haven't personally run across it, but here's a few examples:

* Registers. C doesn't have a concept of registers [2], and there's not much of an easy way to really distinguish between "things that look like a load/store because the abstract machine assumes everything has a memory location" and "no, this is meant to actually issue a hardware machine load/store or this is meant to actually permanently live in a register." There's also minor stuff like the fact that the language makes it easier to express "A[i]" (load A + i * sizeof(A)) over "&A[i]" (A + i sizeof(A)) that makes it somewhat annoying if you want to express assembly concepts better.

SIMD vectors. This is pretty common (at least across a desktop, server, or mobile CPU or GPU). But C has no way of expressing these types or how to use them, outside of compiler extensions (and there's like three incompatible versions of it).

* There's a lack of concept of optimization, and concomitant issues like optimization barriers. Some things have slowly moved in (e.g., there's now an attribute to indicate a function call is speculatable), but in general, it's still difficult to tell the compiler to stop doing some optimization that might break your code.

* No hardware speculation barrier concept, and similar other barriers for more exotic concepts like operations depending on the path condition of the function call (cryptographic code, which wants to be constant-time, or SIMT code tends to care about that a lot more).

[1] Or at least what people assume the semantics of the abstract machine are. Let's be frank, the C userbase isn't very good at actually knowing what the C standard does and doesn't guarantee.

[2] Yes, I know about the register keyword. No, it doesn't give C a meaningful concept of registers.

To get to memory safety with C:

- Add support for array bounds checking. Ideally with the compiler doing the heavy lifting and providing to itself that most runtime bounds checks are unnecessary.

- Implement trivial dependent types so the compiler can know about the array size field that is passed next to a pointer. AKA

void do_something(size_t size, entry_t ptr[size]);

- Enforce the restrict keyword. This is actually the tricky bit. I have some ideas for a language that is not C, but making it backwards compatible is beyond where I have gotten. My hint is separation logic.

- Allow types to change safely. So that free() can change the type of the pointer passed to it, to be a non-dereferencable pointer (whatever bits it has).

This is an idea from separation logic.

Allowing functions to change types of data safely could also be a safe solution to code that needs type punning today.

I think conceptually modules are great, but if your goal is source compatible changes that bring memory safety then something like modules is an unnecessary distraction.

Any changes that ultimately cannot be implemented in the default C compiler I don't think will be preferable to just rewriting the code in a more established language like Rust.

On the other hand I think we are in a local maxima with programming languages and type systems. With everyone busy recombining proven techniques in different ways instead of working on the hard problem of how to have assignment, threading, and memory safety. Plus how to do proofs of interesting program properties with things like asserts.

Unfortunately it appears that only through proof can programs be consistent enough that specific security concerns can be said to not be problems.

What I have seen of ADA Spark lately has been very tantalizing.

I have a personal project that I think I have solved the memory safety problem, while still allowing manual memory management and assignment. Unfortunately I am at a stage where everything is mostly clear in my head, but I haven't finished fleshing it out and proving the type system, so I really can't share it yet :-(.

While implementing modules, memory safety, type variables, and functions that can change the types of their argument pointers. I think I will end up with something simpler than C in most respects.

I keep going well that doesn't make any sense today, as I go through all of the details and ask why is something done the way it is done.

One of those questions is why doesn't C use modules.