There's one thing that I've on my mind: file headers.

Well I guess you'll use .d as your exentension with you source files, well I do the same. Actually not a problem, I guess nobody will use two experimental languages at the same time :o)

However one proposal that could ease the life for uses in the future is a file header. Some token on the very top that identifies the language as such.

BTW: You'll not be able to call the ""D"" compiler "dc" on unix systems, that abbreviation is already taken on almost all systems by "an arbitrary precision calculator".

Additionally I have a language version info, it allows the language to evolve. That's something one can discuss about, and if somebody is not convinced that's okay, but an language identifier is something I would consider a nice feature.

It would also allow to write in example a compiler that understands two or more languages. It could switch over to the matching parser after it read the identifier token(s). Who knows how far the grammatics of different projects actually differ in future?

Well especially in an "open standard" as what you're seeming to aim for, an identifier for a source file which uses "properitary" language extensions might something beeing worth to consider. A compiler can than in example quickly tell it will not understand that file.

- Axel

I've thought of that too. I wish Bjarne had added one to C++ to distinquish it from C.

-Walter

Axel Kittenberger wrote in message <9loanv$2033$1@digitaldaemon.com>... There's one thing that I've on my mind: file headers.

Well I guess you'll use .d as your exentension with you source files, well I do the same. Actually not a problem, I guess nobody will use two experimental languages at the same time :o)

However one proposal that could ease the life for uses in the future is a file header. Some token on the very top that identifies the language as such.

BTW: You'll not be able to call the ""D"" compiler "dc" on unix systems, that abbreviation is already taken on almost all systems by "an arbitrary precision calculator".

Additionally I have a language version info, it allows the language to evolve. That's something one can discuss about, and if somebody is not convinced that's okay, but an language identifier is something I would consider a nice feature.

It would also allow to write in example a compiler that understands two or more languages. It could switch over to the matching parser after it read the identifier token(s). Who knows how far the grammatics of different projects actually differ in future?

Well especially in an "open standard" as what you're seeming to aim for, an identifier for a source file which uses "properitary" language extensions might something beeing worth to consider. A compiler can than in example quickly tell it will not understand that file.

- Axel