For a little language I designed, I decided that keeping the evolutionary pathwa...

Animats · on July 5, 2017

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 · on July 5, 2017

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 · on July 5, 2017

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 · on July 5, 2017

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

sitkack · on July 5, 2017

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 · on July 5, 2017

> 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 · on July 6, 2017

> 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 · on July 7, 2017

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 · on July 8, 2017

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 · on July 5, 2017

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.