C for All
There are a lot of features thrown into this language that don't seem worth the learning costs they incur. What are the problems you're really trying to fix? Focus on the things that are really important and impactful, and solve them; don't waste time on quirky features that just make the syntax more alien to C programmers.
* `if` / `case` / `choose` improvements look fine, though not that important.
* Exception handling semantics aren't defined.
* `with` is pointless and adds gratuitous complexity to the language.
* `fallthrough` / `fallthru` / `break` / `continue` are all just aliases for `goto`. It's not obvious to me that we really need them.
* Returnable tuples look very nice.
* Alternative declaration syntax looks like a nightmare. If we were redesigning C from the ground up, a different declaration syntax might be better, but mixing two syntaxes is a terrible, terrible idea.
* References. Why? They only add confusion.
* Can't make head or tail of what `zero_t` and `one_t` are about, or why they would be useful.
* Units (call with backquote): gratuitous syntax, unnecessary and confusing.
* Exponentiation operator: gratuitous and unnecessary.
It looks like most people here are so eager to jump on the "this feature is good, this sucks, overal I'm not impressed"-bandwagon (with the typically unwarranted strong opinions that programmers always have when it comes to this) that they didn't bother to explore the rest of the website in more detail. Go to "people" page and you see that it's a language implemented by professors, PhDs and master students from the Programming Language group at Waterloo[0][1]. Scroll down and you'll see that a number of these features came from the master thesis of a student:
So basically, it's a research language, more-or-less developed one student at a time.Alumni Ph.D. Glen Ditchfield, 1992 Thesis title: Contextual Polymorphism Masters Thierry Delisle, 2018. Thesis title: Concurrency in Câ. Rob Schluntz, 2017. Thesis title: Resource Management and Tuples in Câ. Rodolfo Gabriel Esteves, 2004. Thesis title: Cforall, a Study in Evolutionary Design in Programming Languages. Richard Bilson, 2003 Thesis title: Implementing Overloading and Polymorphism in Cforall David W. Till, 1989 Thesis title: Tuples In Imperative Programming Languages. USRA Andrew Beach, Spring 2017. Line numbering, Exception handling, VirtualsI'm all for the evolution of C, but this list...
1) has some downright idiotic things (exceptions, operator overloading)
2) has a few reasonable, but mostly inconsequential things (declaration inside if, case ranges)
3) is missing a few real improvements (closures, although it is not clear whether the "nested routines" can be returned)
This has been tried many times before, and eventually all these attempts die a lonely death. Why use extensions anyway? If one desired the luxury of modern scripting languages, switch to C++, Rust, Go or one of the other alternatives the article mentions.
Looks pretty ambitious. My take from skimming:
* switch, if, choose and case extensions look good.
* I can see the justification for labelled break/continue, but looks pretty hairy. Might discourage rethinking and refactoring to something simpler.
* I'm wary of exceptions.
* I don't like the 'with' clauses.
* Weird to add syntax just for mutexes, but they integrate concurrency/coroutines later, so maybe it make sense.
* Tuples are generally useful, but C11's unnamed structs are generally good enough, ie. instead of [int, char] you can return "struct { int x0; char x1 }" or something.
* New declaration syntax is welcome, but the old syntax probably isn't going away, so I'm not sure it's a good idea.
* Constructors/destructors are good. Syntax looks weird though.
* Overloading is very welcome.
* Not sure about operators, but they have their uses.
* Polymorphism is welcome, though it looks a bit cumbersome, and it should come with a monomorphisation guarantee for C.
* Traits seem like too much for a C-like language. I can see the uses, and the compiler can optimize this well, but they're probably too powerful.
* Coroutines are cool.
* Streams look interesting, but the overloading of | will probably be confusing.
GNU C is probably my favorite extension of C. There's a lot of good stuff in there. The vector extensions make it really easy to write platform agnostic SIMD code.
Considering how hard it is to write truly exception-safe C++ and considering how major C++ code bases don't allow exceptions, adding exceptions to C does not seem like a good idea.
Without continued development of the language, C will be unable to cope with the needs of modern programming problems and programmers; as a result, it will fade into disuse.
C11 is pretty nice! C99 is too. One might think that "almost once a decade" is kind of slow for updates, but M$ have enough trouble keeping up with the current schedule. Of course TFA describes a possible direction for C2x, but they could have a more charitable attitude...
This is the wrong way to go about it. The syntax is great, what is needed is updates to reflect modern hardware:
-Vector types. (With arbitrary sizes not just up to vec4 for like on GPUs)
-New operators like clamp, and other intrinsic. (See GLSL and modern instruction sets)
-Min/max: |< >|
-Dot:
-Cross product: ><
-Swizzle: a.3.2.1.0
-Qualifiers for warping behavior.
-Standard library with cash management hints.
-Define qualifiers for padding of structs to be defined.
I would also argue you could change some things in the spec to make it easier for compilers to optimize, like making the calling a switch without a catching case undefined behavior.
As for the syntax itself, I could find being able to type multiple break commands in a row to get out of more then one loop useful, but its not a big thing.
I would probably drastically restrict the power of the pre-processor too.
(If you have too much time on your hands: https://www.youtube.com/watch?v=443UNeGrFoM)
Peter Buhr also teaches CS 343: Concurrent and Parallel Programming [0] at the University of Waterloo in a dialect of C++ that he has been working on [1], called uC++ [2].
[0] https://www.student.cs.uwaterloo.ca/~cs343/
IMHO there are better proposals for a "better C" language which fix some of the shortcomings of original C:
As long as the language is small and has good tooling, and (most importantly) can easily interoperate with C libraries (have a look at Nim for an really awesome C integration), it doesn't matter whether it is backward compatible with C.
C itself should stay what it is. A low level and simple language without surprises which is only very slowly and carefully extended. Languages that are developed "by committee" and add lots of new features quickly are usually also quickly ruined.
C is an evolving ISO standard.[1] We are currently at C11.
> The purpose of the project is to engineer modern language features into C in an evolutionary rather than revolutionary way.
It's also the purpose of the standards body. Why not propose these changes to the standard?
If there's one thing I would do to C it is to replace the normal datatypes with u8, u16, u32, u64 (ad infinitum) and their signed brethren s8, s16, s32, s64, ...
And don't start with the stupid (u)intXX_t.
From https://plg.uwaterloo.ca/~cforall/features:
I hope thatâs a documentation error. Otherwise, it seems designed for the âObfuscated C for allâ contest:Exponentiation Operator New binary exponentiation operator '\' (backslash) for integral and floating-point types. 2 \ 8u; // integral result (shifting), 256 -4 \ 3u; // integral result (multiplication), -64
Does what â\â does really depend on the sign of i?int i = f(); int j = i \ 3u;So the mailing list and the other stuff are "internal only"? How is possible for external individuals to take part?
Did they bother to ask any C developers what the pain points are? The kernel, qemu, libvirt, coreutils and gnulib developers really use C and POSIX to breaking point, and have some real problems that might be addressed in the language, but I don't see much evidence of those problems being addressed here.
Did they study existing code bases and bugs to find out how applicable these changes are to fixing real problems?
In my opinion, what C is lacking isnât primarily language features - itâs: 1) a common, readable style standard that people can agree on 2) modern agreed-upon idiomatic ways to write readable and safe code. There are certainly common C idioms but many exist for historical reasons and not because theyâre necessarily the best things to do, and 3) a standard library that exemplifies the above two things, provides common functionality needed between projects, and fosters a sense of community
Efforts like those of the poster donât really address these things.
When I tell people I like C, the response differs depending on experience level. Less experienced people who havenât spent time in C++ either will say âGross, pointersâ. People used to C++ will say âwhat about templates and constructors/destructorsâ, and âare you going to write your own library for vectors and maps every time?â And people who are experienced (more experienced than me) and like C have generally said that the main things they miss from C++ are constructors and destructors (and mostly destructors), and templates (but only for container types), but that they can live without them.
C is a small language that can be relatively easy to write (once you pick/write a suitable stl-equivalent), and extremely easy to read (and to the extent that you can look at a line and know exactly whatâs going on under the hood). IMO it should stay that way.
Take a look at zproject [0] for what I think is a good effort to standardize C style and project structure. Even if you disagree with the particular design choices, the spirit of it is what I think is needed to keep people from just assuming C is for dinosaurs.
I think I would prefer the Indiana Jones approach. "Leave it alone! It belongs in a museum!"
The (draft) ISO C11 spec is already nearly 700 pages[1]. How can anyone justify adding something like "choose" (a switch() without fall-throughs) to such a language?
Who are these people[2], and what is their mandate? Did they actually consult with the likes of Linus Torvalds, Greg KH, Mike Pall--those who actually use C every single day on mission-critical projects like OS kernels and virtual machines--and ask them what improvements to C they need?
1) http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
From https://plg.uwaterloo.ca/~pabuhr/:
> The ability to write generic reusable programs, called polymorphism, is fundamental to advanced software engineering. I am interested in static type-systems providing polymorphism without the use of subtyping. The problem with subtyping is that it imposes significant restrictions on reuse when static type-checking is required. This work has resulted in a new dialect of C language, called Cforall, which adds parametric polymorphism and extensive overloading to provide a more general type-system.
Please smart people, spent your intelligence on clean approaches such as memory-safe system programming languages such as Rust or so instead of wasting time with old broken legacy languages. I want to see secure systems before I die.
I studied the documentation, basically 80 percent of what is added is not what is needed for C to become better, in my opinion.
"Without continued development of the language, C will be unable to cope with the needs of modern programming problems and programmers; as a result, it will fade into disuse. Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language."
Really? Lots of C code written today is written using C89/C90 or C99 std. I think if it's something that history tought us it is that C does _not_ need to be transformed into something else or we would already be happily using this "something else" today.
Wow, they really hate object-oriented programming.
It's the one thing they immediately emphasize that their language isn't, and it's the one example they give for "disadvantages of multiple legacy design-choices".
We already have this. Just use C++ and stay away from the features you don't want. If you want to enforce specific restrictions then start an effort to provide a formal C++ feature restriction specification.
A beautiful, and simple, addition to the C language would be a mechanism to assess the remaining stack size. This is trivial to check in assembler, but practically impossible in portable C.
Indeed, thanks to VLA, the stack can be used as a clean notation for raii. You just replace this ugly, but very common, construction
with thisvoid f(int n) { float *x = malloc(n * sizeof*x); // ... free(x); }void f(int n) { float x[n]; // ... }uWaterloo uses an in-house language to teach advanced control flow, in my days it was uC++ built by Peter Buhr in CS343. They might have opted to use C for All now.
I've found it quite easy to spin up parallel tasks in uC++ if I needed both C++ and easy-to-use parallelism, the language isn't formally supported but for small student projects its pretty kick ass, also the prof who built it is just quick email away.
So all I'm all in favour of C for All as an alumni, hopefully it enriches the existing curriculum.
Hmm, we took a different approach, here's my C-like dialect (built on Tcl's byte codes so it co-exists with Tcl code. And yes, I know, but we needed Tk so were stuck with Tcl).
Stuff that I'd like to C in an evolved C:
regexp engine as part of the language so you can do
<> and <FD> from perl, just handy.while (buf = <>) if (buf =~ /some regexp/) puts(buf);Lists as a built in, with any element type and builtins like push, pop, shift, unshift, etc. Again, more perl goodness without all the @'s and $'s.
${expr} interpolation inside strings. Like shell, and it's handy.
At this point I'm just typing in the L language docs, so most of the stuff here:
http://www.little-lang.org/little.html
BTW - the logo for the language is a tip of the hat to the things that inspired it: the Tcl feather logo, the Perl camel logo, and "C" all bunched together. I'm very fond of that logo but not sure that anyone but me gets it.
Oh no :(Exception HandlingI've had renewed interest in C recently, having been away from it for nearly 10 years. This renewed interest comes from working with golang for the last few years, and has caused me to find this book[0] which discusses ways to implement OOP ideas in pure C. Not to promote Go, or OOP, but rather I wonder if selecting useful idioms form modern languages wouldn't be a better intermediate step to updating C, then language level changes.
Not bad, but not much to call home about either.
Personally, I would like to see better support for immutability/purity and more first-class functions (does C still insists on functions to be global in scope?).
Also, I think user-defined constructors/destructors are a bad idea. I generally found that any side effects that are done in constructors and destructors are a nasty source of bugs. It's almost always better to use a factory method (function), which makes user-defined constructor/destructor useless as a concept.
This is stupid. C accepts too many programs already. Rust mainly improves by accepting fewer. The few compatability-breaking changes this includes don't go far enough to matter.
>While C++ had similar goals, it has the disadvantages of multiple legacy design-choices (e.g., object-oriented)
How many people agree with this statement? OO is a legacy design choice or in other words: a bad design choice.
I agree with the statement, so do most modern languages like rust and golang but I wonder what do non language designers think? This statement was given as if it was obvious but many programmers who I work with still think OO is the greatest invention ever.
Everyone wants to cripple switch by turning it into the structure variously known as cond, when, match, etc. If you can only have one, by all means, take the cond, it will be useful more often, but switch's computed goto is a very useful thing to have in reserve.
What's with the weird cryptic, trigraphish syntax for something common as constructors and destructors?
How are _init(struct obj o) _cleanup(sturct o) not enough? Okay, except those rare cases when you need a _new(struct obj o).
The biggest evolution for C, to cut down bugs to 1/10 would be to have a proper built-in string type -- one that easily transforms into the relevant C type, and that keeps the size.
(And maybe a vector and hashmap).
I'm personally in favour of this proposal, I'm sick of having to write function pointer when implementing objects in C. Looking forward to seeing this in the next C standard
undefined
looks like the University of Waterloo isn't on the cloud!
Anyone else having trouble accessing the site?
Hallelujah.
I think C developers are harder to convince than developers who more regularly consume modern languages. I see no reason to use this over ANSI C.
Should have fixed the easier problem first. The 'searchability' of the language name.
If we could just sit down and agree to standardize most of the GNU extensions; nested functions, cleanup attributes and computed gotos to name some; that would take us much further than any attempt at reinventing the whole thing. I don't know if they all start misinformed, or if they get caught up in their egos along the way; but none so far has managed to produce anything that even comes close to replacing C.
I see they are adding an analog of the C++ iostreams, but I don't see a discussion of how to disambiguate between `sin' as in stream-in and `sin' as in the mathematical function.
Really, they should introduce some kind of modules or namespaces. Of course, C++ already has namespaces and will have modules sooner or later...
Site is down... that doesnât exactly bode well for an article seemingly about programming.