BruceIV

You can do this sort of search in Firefox as well. Right click on pretty much any search box, then click "Add a Keyword for this Search..." You'll get an add-bookmark dialog that you can put a keyword into (e.g. "w" for Wikipedia) -- I like to save the resulting bookmark in "Unsorted Bookmarks" so that it doesn't clutter up my menus. After that just typing "w Firefox<enter>" in your address bar will bring up the Wikipedia page for Firefox.

The initial implementation was finished in '03, and we revived the project somewhere around '15, so your guess about a research project that was recently taken back up is correct.

We intend to write a "proper compiler" at some point (probably either a Clang fork or a Cforall front-end on LLVM), but it hasn't been a priority for our limited engineering staff yet. I think we are getting a summer student to work on our debugging story (at least in GDB -- setting it up so it knows how to talk to our threading runtime and demangle our names), and improving our debugging capabilities has been a major focus of our pre-beta-release push.

[on the Cforall team] we actually take advantage of this same VLA idiom for temporary storage for polymorphic variables.

Fun fact from when we switched our implementation to use VLAs: if you call alloca() for stack memory instead, it doesn't work properly inside a loop, because it never releases the memory until the stack frame is exited.

A polymorphic function is one that can operate on different types[1]. You would maybe be familiar with them as template functions in C++, though where C++ compiles different versions of the template functions based on the parameters, we pass extra implicit parameters. The example above translates to something like the following in pure C:

    void* malloc_T(size_t sizeof_T, size_t alignof_T) {
        return malloc(sizeof_T);
    }

    int* i = (int*)malloc_T(sizeof(int), alignof(int));

In this case, since the compiler verifies that int is actually a type with known size (fulfilling `sized(T)`), it can generate all the casts and size parameters above, knowing they're correct.

[1] To anyone inclined to bash my definition of polymorphism, I'm mostly talking about parametric polymorphism here, though Cforall also supports ad-hoc polymorphism (name-overloading). The phrasing I used accounts for both, and I simplified it for pedagogical reasons.

[on the Cforall team] FWIW, the Go docs are somewhat ambivalent on the OO nature of Go[1]. Along similar lines, our main objections to object-orientation are that, in "traditional" implementations like C++ or Java, it tightly couples a number of features that we believe would be better served by a more orthogonal design.

More specifically, C++-style OO couples (1) in-memory layout of types, (2) behaviour of objects, (3) encapsulation boundaries, and (4) the hierarchical "is-a" relationship. In Cforall, (1) and (3) are handled by the usual C mechanisms of struct types and translation-unit boundaries [we go to great effort to maintain C-style separate compilation, though we will likely build a better namespace/module system at some point], (2) by traits, and (4) by a yet-to-be-implemented system of RTTI for specific "inherited" types [likely when the undergrad RA who started our exceptions implementation comes back as a Master's student this fall].

As you mention, many use-cases (including widgets in GUIs, but also abstract syntax trees in compilers) require some sort of heterogeneous collection type to work properly, and for this OO is the right model. We just don't want to force the entirety of that model on every use case, so we can just take traits when we want to write a polymorphic function over related types or an ADT like "Set" which requires its keys be sortable, or just take RTTI for exception handling, when the set of exception types we're handling is known statically, but we need to determine if the thrown exception inherits from one of the caught types.

[1] https://golang.org/doc/faq#Is_Go_an_object-oriented_language

[on the team] It helps if you use the official ASCII spelling, Cforall -- a DuckDuckGo search for "Cforall" in private browsing mode pulled up our homepage first result. (I have no idea who the OP for this thread is, they're no one associated with the team.)

It's maybe not quite what you're looking for, but Cforall's polymorphic functions can eliminate nearly-all the unsafety of void-pointer-based polymorphism at little-to-no extra runtime cost (in fact, microbenchmarks in our as-yet-unpublished paper show speedup over void-pointer-based C in most cases due to more efficient generic type layout). As an example:

    forall(dtype T | sized(T))
    T* malloc() {  // in our stdlib
        return (T*)malloc(sizeof(T)); // calls libc malloc
    }

    int* i = malloc(); // infers T from return type

Transpiles-to-(GNU-)C -- it was first written before LLVM, if we were starting the project today it would likely be a Clang fork.

[On the Cforall team] For what it's worth, one of the features Cforall adds to C is RAII.

The exception implementation isn't done yet, but it's waiting on (limited) run-time type information, it already respects RAII.

[also a CS 343 TA] I personally agree with you -- if it were up to me I'd refactor CS 343 into a pair of courses, maybe focusing on high-level concurrency constructs with a follow-up course on building that sort of runtime system.

[on the Cforall team -- also a CS 343 TA] We've incorporated the main uC++ feature set into Cforall, but are still using uC++ for 343; maybe in another couple years when Cforall is stabilized a bit we'll give it to the students.

[on the Cforall team] One of our Master's students has incorporated the majority of the uC++ features into Cforall as well, with some neat extensions for multi-monitor locking in a way that doesn't introduce synchronization deadlocks not present in user code.

[on the Cforall team] It broadly matches our other operator-overloading syntax, where the ?'s show where the arguments go, e.g. ?+? for binary addition, ?++ for postincrement and ++? for preincrement. For something as common as constructors and destructors, a concise syntax is a desirable feature.

IIRC [not the team lead] they approached us when they were looking for modernization options for their existing C codebases. From there it went through the usual university-corporate research partnership process.

Zig looks neat, BTW.

Most programming languages do an initial period of internal development before a public release.

When I started on the project ~3 years ago, it took me about 2 weeks to work around the (then current) set of compiler bugs to make a 100-line benchmark program -- naturally a public release at that point would not have been fruitful. Today our compiler generally works, and we're looking forward to making a public release once we get a couple more features stabilized.

[actually on the Cforall team] This is basically our pitch -- the last 30 years of language design features applied to a language that is not only source-compatible with C (like C++), but actually maintains the procedural paradigm of C (unlike C++) -- idiomatic C code should require minimal to no change to make it idiomatic Cforall code, and skilled C programmers should be able to learn the extension features orthogonally, rather than needing to figure out complex interactions between, say, templates and class inheritance. We are working in the same space as C++, and do draw inspiration from C++ where useful, but with the benefit of decades of watching C++ try things to see where the important features are.

There's also some really neat language-level concurrency support; work is ongoing on new features and a shorter summary, but you can see one of our Master's student theses for details: https://uwspace.uwaterloo.ca/handle/10012/12888

[actually on the Cforall team] Huawei has funded the project for the past couple years, the web server is just our university research group's web host, which we didn't expect to get this much traffic on (it wasn't one of us who put this page on HN). We've been running fairly low-profile for the moment, but should make a beta release later this summer.

I'm actually on the Cforall team -- we've been running fairly low-profile for the moment (it wasn't one of us that posted the homepage to HN), but plan on making a beta release of the compiler and stdlib sometime this summer.

If you're interested in working on the project though, more hands are always welcome; I'd suggest contacting our team lead, Peter Buhr, his email is pabuhr AT the university domain Cforall is hosted on.

A thousand times this; I've been working on compiler-y things in C++ for the past couple years, and I am firmly convinced that the visitor pattern is a truly inadequate way to attempt to compensate for the lack of a proper destructuring pattern-matching construct in a language.

There's some really good YA genre fiction out there, but I think one of the defining aspects of the genre is it's written about teenage protagonists with a number of very teenage problems, which I find increasingly tedious the further I get into my twenties.

That said, Marissa Meyer's Lunar Chronicles (to pick a somewhat less known example) are pretty excellent sci-fi, if you can get past the annoying teenage romances of the protagonists.

I've been working on a derivative parser for PEGs; it's not quite working yet, but the inherent lack of ambiguity in PEGs is helpful to the time bounds there (I think I can make it worst case cubic, and linear in a lot of common cases). I've got some ideas how to modify the algorithm to a better derivative parser for CFGs; I should be able to recognize arbitrary CFGs in linear time, and I think parse them in cubic (carrying around the set of current parse tree options is expensive, but I think if you store them as a DAG of parsing paths rather than a parse tree you can make it tolerable).

As the original article points out multiple times, recursive descent can take exponential time, even for an unambiguous grammar.

Even if there's no publicly published code, any credible CS researcher will give you access to their code and tests for research purposes if you ask (excepting the rare case where they include someone else's IP), for exactly this reason of reproducibility.

Secondly, testing in a number of different environments is part of the nature of scientific reproducibility, to check if the claimed result is robust or simply an artifact of the experimental setup, so releasing more detailed specs of the hardware used is not so essential.

The author said the PLDI 2008 paper and the ESOP 2013 papers.

Interesting post, but what the author doesn't seem to realize is that even though he isn't doing much generic programming, someone needs to be able to do it to write the libraries he needs to use. The proposed approach is decent, but it reminds me of wrapping up STL container types in the amount of useless boilerplate needed to achieve a single function (but worse, because here the function is "type safety", whereas when you wrap an STL type it's about e.g. ensuring some invariant on the members of a set)

Odd that an article so nit-pickily concerned with the accuracy of the mathematics of Turing's work would over-generalize the actual computation he proved to be impossible, which was deciding if an arbitrary algorithm terminates on all possible inputs (i.e. there are no infinite loops), to "there are no bugs".

The Annotated Turing is a great book though, I highly reccomend it (Turing's original paper is _very_ dense).

`gcc -E foo.c` will just run the pre-processor and print to stdout (including expanding all the `#include`s, so it's a bit verbose).

I've got an Asus Memopad FHD 10 that's running Intel; it was about $30 cheaper than anything similarly specced last Christmas, and I've been generally pleased with it (although system updates tend to break Hangouts for a bit, which I blame on the uncommon platform).

Thanks; it's just a present irritant because the Hangouts client for iPad is presently broken (no video), and Skype doesn't support video conference calls in their tablet clients, so I don't have a free cross-platform multi-way tablet-based video-chat protocol that works, and another entry in that space would be convenient.

I'll believe it when I see it; I'm still waiting for the promised open-source release of the Facetime protocol.