On Tue, Jan 3, 2017 at 3:39 PM Tim Bradshaw <tfb@tfeb.org> wrote:

I think you can do so only if every language processor you ever expect to deal with your code is lexically-compatible: you *can't* do so if the lexer will puke: you need some frontend which will prevent the lexer ever seeing the toxin, and that thing is what Lisp would call read-time conditionalization. Plan 9 and Go both avoid this problem by being single-implementation or nearly-single-implementation systems: many things are easier with that assumption.

Well, if by single-implementation, you mean single-compiler, I have a counter example: Harvey is Plan 9 with just enough changed to be C11 compliant. All of userland, libraries, and kernel build and boot with gcc 4, 5,6 and clang 3.5, 3.6, and 3.8. Harvey builds and boots on amd64 and riscv. We've adhered as much as we can to the coding style of Plan 9 and we've seen the benefits. Probably the only major change was removal of anonymous struct members, and that actually improved the code as it uncovered some long-standing driver bugs.

In contrast, it's very hard to build portable code that uses extensive ifdefs and 'modern' tools like libtool today. Just the other day I had a build failure because something needed autotools x.6.61 and I only had x.y.60. Portable seems to now mean 'builds on ubuntu AND Fedora!' and even that's rare.

The portability principles used in Plan 9 work just fine with 'modern' compilers. The cpp abuse we see in so much code today seems completely unnecessary to me. C code written with #ifdefs and libtool is far less portable than it might be.

ron