1. 14

  2. 2


    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.

    1. 1

      Anyone have speed tests on how much one can stress the nim compile-time runtime?

      1. 1

        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.

        1. 1

          I don’t follow… Can you break it down for me?

          1. 1

            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.