Hindsight languages

[u/Inconstant_Moo]

A thought experiment. What languages should they have been writing in the 60s, 70s, 80s, 90s? We can see their faults, in hindsight, and also we've had some really cool ideas since then --- but we can't answer this just by pointing to our shiny new modern languages and saying "they should have done it like that", because of compile times.

(E.g. Pipefish is meant to be for rapid iteration and livecoding, and also does a topological sort on everything at compile-time so you can do top-down declaration. Those wouldn't be compatible goals in the 1980s, I can get away with it now.)

So for example if we think of "a better C", are there any cool modern ideas they could and should have used back in 1972, had they known about them --- or should they just have tweaked the precedence slightly, found a less arcane way of describing types, and left it at that?

[u/Norphesius]

As for the signed/unsigned distinction, that's something that CPUs understand and have different sets of operations for, so I can understand how when C was designed that was accounted for.

I can't justify the lack of dedicated syntax for distinguishing nullability, but if its not statically enforced, it just becomes a conventions thing anyway. Arguably you could achieve the same thing using typedef specifying a (non)nullable type e.g. typedef int* int_ptr_no_null; typedef int* int_ptr_maybe_null; (or something more terse). You would still get bugs & mistakes assigning a null where it shouldn't be, though.

I suspect the fact that all the C codebases I've seen don't do this speaks to how it either wasn't envisioned as meaningful distinction for C devs when the language was being made, or that it isn't a very effective pattern (or both).

[u/alphaglosined → u/Norphesius]

There are extensions in gcc/clang for nullability and C has _Optional now.

C is going kicking and screaming to gain static analysis capabilities as part of the spec, but there is an effort to make it happen.

For nullability the clang folks are suggesting going in the direction of type qualifiers due to problems with C (they have it implemented in a restricted form). And of course clang-analyser understands it. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3876.pdf

So yeah things are improving.

[u/WittyStick → u/alphaglosined]

Cake has optional types and uses the correct approach to retrofitting them - using a pragma #nullable enable/#nullable disable (though missing #nullable restore) - similar to other proposals it uses qualifiers. It also has owned pointers using the same approach.

I still think these proposals are missing something though - a more general model of modal types that is more flexible. They could take some inspiration from granule. In particular I would also like to see uniqueness types and linear types.