4 ms·
> ... generics, traits ... Again, these are just as much a single feature as Zig comptime. Traits are like comptime types, or else (closer to what Zig does) co
by Rusky 7y ago
> ... generics, traits ...
Again, these are just as much a single feature as Zig comptime. Traits are like comptime types, or else (closer to what Zig does) comptime type variable introspection.
> You'd get similar compile-time errors as you would get, at runtime, in, say, Clojure or Python.
Exactly- you're not writing plain Zig, you're writing a Zig-adjacent dynamically typed language with new ways to do almost everything and different tradeoffs around correctness.
> just call a subroutine at compile time.
Whoever wrote that subroutine did the reimplementation by hand.
- pron 7y agoYou're looking at this differently from me. The way I see it, Zig is not, say, C, with an extra compile-time language to replace macros. It's a simple dynamic language, with optional typing, where you select which code runs at compile time and which runs at runtime. Aside from being quite revolutionary in that respect (precisely because the compile-time code doesn't operate on the AST, like in Lisp, but on program objects) -- languages like Nim and Zig have a similar feature, but they also have other features -- it has certain big practical implications. For one, you could imagine stepping through a Zig program with a debugger at compile-time, seeing how it operates on Zig objects, not produces an AST that goes through another stage. For another, in terms of program semantics and analysis, the program means the same thing as if the language were truly dynamic and everything was evaluated at runtime. I.e. Zig has the semantics of a very simple dynamic language. So the subroutines that run at compile time and that you or someone else writes, are just simple Zig code you can read (and maybe, some day, step through).