Hacker News Reader

Comment by VLM | Hacker News Reader

I think its part of the quaint appeal of the article, that c-- only supports i386 but the way the world moved did not require c--, FSF supported GCC supports something like 50 archs and many more not officially FSF supported. And GCC is hardly the only c compiler out there. The world just didn't move in the direction directly requiring c--.

Now as for current ideas and projects similar in concept to c--, that is interesting to think about.

Maybe the startup lesson is sometimes, if you try to intermediate yourself as a middleman, even if you do a good job of it, and appear to be a good idea, it just doesn't work. It would be interesting to dissect the c-- experience and figure out why.

View on HN

GCC did already exist when the C-- project was started, so that part didn't really change. The C-- team's hypothesis was that some kinds of languages (especially functional languages) would benefit from a cross-platform layer that is a better compilation target than C, partly through being a bit more low-level. The previous two popular routes were native-code compilers and compile-via-C compilers. Native-code compilers have the disadvantage that porting them and maintaining them on N architectures is significant work, and compile-via-C compilers have the disadvantage that C isn't a very convenient compilation target for many language features, especially to efficiently compile some common FP language features. The hope was that C-- would be a nice middle ground between compiling via C and compiling to native code, producing a target that was nicer than C as a target.

Imo, that hypothesis did have some legs, but people are now instead usually using LLVM in various ways to accomplish it. LLVM's intermediate representation isn't really properly cross-platform, but it can be sort of hacked to be used for that purpose.

Do you think LLVM IR covers this ground adequately, despite not being cross-platform?

I'm not really a language implementor, more of a spectator of language implementations, so someone with more experience would give a better answer.

My impression is that the GHC people, at least, still think that C-- is a nicer IR than LLVM-IR for their purposes. But they are slowly moving more things to LLVM anyway, because the LLVM project as a project has, in the meantime, built up a lot more momentum and infrastructure. In the early 2000s this wasn't obvious, but in 2013 it's clear that LLVM has an ecosystem, institutional support, resources to maintain ports, etc., while C-- didn't manage to get the same traction.

From my personal experience, LLVM is tied a bit to closely to the C ABI, which makes it difficult to implement some FP features cleanly. One example is forgoing C's stack discipline to implement double-barreled continuations.

Reply on news.ycombinator.com