1. 10
  1.  

  2. 3

    Would zig compile time evaluation be powerful enough for something like string -> PEG parser as a library?

    1. 2

      The only potential roadblocks I foresee for this use case are:

      • zig compile time code execution is much slower than it should be. It should be able to roughly match CPython’s performance, but it’s much slower and doesn’t free memory. Ironically we actually need to add a garbage collector in compile time code execution.
      • zig compiler doesn’t yet have sophisticated caching that would make it practical to have a really complicated compile time implementation. So you’d wait for your thing to run with every build.

      Both planned to be fixed, it’s just a matter of time.

      1. 1

        That’s interesting, so you have a full Zig interpreter that runs at compile-time?

        But won’t collecting garbage make it slower? Are the compile-time programs allocating so much that they need to free memory?

        I’m curious if any other languages have run into this problem.

        1. 4

          so you have a full Zig interpreter that runs at compile-time?

          It’s a little more complicated than that. Zig AST compiles into Zig IR. Each instruction’s value is either compile-time known or not. Most instructions which have all compile-time known operands produce a compile-time known result. There are some exceptions - for example, external function calls always produce a runtime result.

          If statements and switch statements whose condition/target value is compile-time known, the branch is chosen at compile-time. This means that zig has “implicit static if”. E.g. if you do if (false) foo(); then foo() is not even analyzed, let alone included in code generation.

          In addition, there is the comptime expression: https://ziglang.org/documentation/master/#Compile-Time-Expressions This causes all the branches and function calls - including loops - to be compile-time evaluated.

          But, importantly, you can mix compile-time and run-time code. Variables can be marked comptime which means that loads and stores are always done at compile time.

          For loops and while loops can be marked inline which unrolls the loops and makes the iteration variables known at compile-time. You can see this in action for the printf implementation: https://ziglang.org/documentation/master/#Case-Study-printf-in-Zig

          But won’t collecting garbage make it slower?

          I can’t answer this in a clear way yet as I haven’t tried to solve it. The basic problem is the same as in e.g. Python where you could potentially have 2 compile-time values with references to each other, but not referenced from any root that is actually going to go into the executable, so they should not be in the binary.

          In Debug builds zig has a goal of compiling fast, and willing to create a more bloated binary with worse runtime performance. In ReleaseFast builds, zig can take a few orders of magnitude longer to compile, but the performance should be optimal and bloat should be minimal. So it might be a thing where Zig does not garbage collect comptime values for Debug builds unless it starts to use too much memory, but it would certainly take the time to do this for ReleaseFast builds.

          Are the compile-time programs allocating so much that they need to free memory?

          I don’t personally have any use cases where that is true, but in general, I could create a program that allocates an arbitrarily large amount of memory at compile time in order to do a computation, but that value is not ultimately used in the binary, yet the memory allocated has references to each other, and so it would fool the reference counter.

        2. 1

          Ironically we actually need to add a garbage collector in compile time code execution.

          Why? It seems like if you allocate and free as you would in normal Zig, this wouldn’t be a requirement.

          1. 1

            Thats really cool, things like regexes or sql statements could be pre-prepared at compile time with features like this.