[cronjobber]

For a little language I designed, I decided that keeping the evolutionary pathway open means introducing new keywords once in a while. But we don't want to break existing code; code is expensive. Valuable. We don't want to break valuables!

So I added a mandatory file header to the language which (amongst other things) specified the language version.

I thought this was a win... with one exception that would have bothered me a lot if this had been a language intended to achieve world domination:

Mandatory version headers totally ruin your "hello, world!" comparison chart story ;-)

[Animats]

Mandatory version headers totally ruin your "hello, world!" comparison chart story ;-)

Once, when the C standards committee was struggling with the semantics of "main" under Windows, I suggested that "main" not be part of the language at all. You would include <unix.h> or <posix.h> or <dos.h>, and get "int main(int argc; char *argv[]);" as a prototype, which you must define. Or you include <windows.h>, and "int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow);" is the function you must write. The runtime pulled in would call the appropriate function. "main" would no longer be a special case. This was generally agreed to be the correct solution, but too upsetting for beginners.

[JoshTriplett]

It'd be unfortunate to have to include a platform-specific header in otherwise portable code. Why have to include a <posix.h> versus <dos.h> if they both define main the same way? (Windows aside.)

[mrec]

You can use vanilla `main` for Windows apps too, just need to override the default subsystem when invoking the linker. I never understood the point of `WinMain`; IIRC there's nothing it does that you can't do just as well without it.

[jhasse]

Or you can just tell Microsoft that they won't get special treatment and should use `int main(int argc, char* argv[])` ffs.

[sitkack]

I believe this is the only correct answer. Or at least the best answer. Code isn't written in isolation, it is a function of the compiler used. And in a large codebase it will span many compiler versions.

1) Code written against a compiler should continue working

2) New code should be able to use new features and not pinned to an old compiler

3) The language / compiler should be allowed to innovate w/o maintaining strict backwards compatibility for all past code.

I am personally ok with and support having any large scale, long term project require multiple versions of the compiler to build.

[wtetzner]

> I am personally ok with and support having any large scale, long term project require multiple versions of the compiler to build.

Or even better, have every compiler support all versions of the language. It obviously requires some careful architecting to keep it maintainable, but that's better than every user of the compiler having to sort out versioning issues themselves.

Edit: I've re-read your comment, and I can't tell if we're in agreement or not :)

[sitkack]

> have every compiler support all versions of the language

If having an interface that looks like the compiler do this, I am fine with it, but a single codebase ... not so sure. Large systems collapse under their own weight, having to support all versions when the current-4 already supports it seems kinda ridiculous.

[wtetzner]

Well, hopefully the changes between versions aren't too big, because at some point it doesn't make sense to consider them to be the same language.

The idea is that each version would still be translated into a common internal representation pretty early on after parsing, so it would almost be like supporting multiple versioned mime-types in a REST API.

And it's probably harder to do with languages that already exist, but if the spec is defined from the start with versioning in mind, then it might not be so difficult.

[sitkack]

These are the things that I think Rust should really be concentrating on. How to make a vibrant language that can support 10-20-50 year codebases and still remain fresh.

[tveita]

If extensibility is a primary concern, it may be worth just putting sigils on all identifiers to make it completely unambiguous.

E.g. the LLVM IR representation takes that route, though admittedly it's not really intended for humans to write.