This reminds me of Jon Blow’s JAI language. He likes that there is no build system, because the build is done by the program itself via compile-time evaluation.
It turns out that in D, if you declare an enum with only one value (in this case a list), it is declared to be a manifest constant. That seems to me like a slightly strange way of getting a compile-time-only value, but I’m not a D programmer.
Actually, I suspect it’s “you’re not a compiler writer who wrangles DWARF debug output format for a living.”
In which case DW_TAG_enumerator is the only / obvious applicable hammer for that particular nail.
Alas, a language designer has a hard choice…. to design a language and write a compiler……
Or design a language and executable format and a debugging information format … and write a compiler and a linker and a debugger and a loader and a way of linking to pre-existing elf code and debugging that…….
Walter Bright and company has wisely opted for the former path.
However I suspect it does, shall we say, ahh, “inform” certain choices.
EDIT: Disclaimer: This is not a D official view… This is a wild arsed guess based on way too much time staring at objdump -S and objdump –dwarf=info for various C / C++ programs.
I think the,
from the C programmers perspective,
strange choice of the enum keyword for this use case….
probably relates to the fact it uses exactly the underlying mechanics
that the compiler backend / linker / dwarf debugger format…
uses for enum values.
It may be tempting to create a new category for these things, but unless you rewrite the rest of the toolchain…. you’re pretty much stuck with being creative with whatever is already there.
Even C repurposes the linker mechanics that was set up for ye olde FORTRAN common blocks, and C++ does horrible post processing on .o files to set up static constructors.
So I think this is a case of a compiler writers perspective leaking into the language design.
If you look really really closely at C constants… and what happens at the assembler / linker / debugger level, they are a bit… ahhh. Strange. Not quite what you’d think on first glance what they mean. And the debugger support for them is ahh, stranger. And there are subtle differences between what C++ and C means as well.
Nice.
This reminds me of Jon Blow’s JAI language. He likes that there is no build system, because the build is done by the program itself via compile-time evaluation.
Anyone have speed tests on how much one can stress the nim compile-time runtime?
Actually, I suspect it’s “you’re not a compiler writer who wrangles DWARF debug output format for a living.”
In which case DW_TAG_enumerator is the only / obvious applicable hammer for that particular nail.
http://dwarfstd.org/Download.php
Alas, a language designer has a hard choice…. to design a language and write a compiler……
Or design a language and executable format and a debugging information format … and write a compiler and a linker and a debugger and a loader and a way of linking to pre-existing elf code and debugging that…….
Walter Bright and company has wisely opted for the former path.
However I suspect it does, shall we say, ahh, “inform” certain choices.
I don’t follow… Can you break it down for me?
EDIT: Disclaimer: This is not a D official view… This is a wild arsed guess based on way too much time staring at objdump -S and objdump –dwarf=info for various C / C++ programs.
I think the,
It may be tempting to create a new category for these things, but unless you rewrite the rest of the toolchain…. you’re pretty much stuck with being creative with whatever is already there.
Even C repurposes the linker mechanics that was set up for ye olde FORTRAN common blocks, and C++ does horrible post processing on .o files to set up static constructors.
So I think this is a case of a compiler writers perspective leaking into the language design.
If you look really really closely at C constants… and what happens at the assembler / linker / debugger level, they are a bit… ahhh. Strange. Not quite what you’d think on first glance what they mean. And the debugger support for them is ahh, stranger. And there are subtle differences between what C++ and C means as well.