9 ms·

It would be nice to have a more indepth discussion of the issues that have been found with compile-time programming, rather than uncritical acclaim. Staged prog

It would be nice to have a more indepth discussion of the issues that have been found with compile-time programming, rather than uncritical acclaim. Staged programming is not new, and people have run into many issues and design tradeoffs in that time. (E.g. the same stuff has been done in Lisps for decades, though most Lisps don't have a type system, which makes things a bit more complicated.) Some of the issues that come to mind: * Implementing generics in this way breaks parametricity. Simply put, parametricity means being able to reason about functions just from their type signature. You can't do this when the function can do arbitrary computation based on the concrete type a generic type is instantiated with. * It's not clear to me how Zig handles recursive generic types. Generally, type systems are lazy to allow recursion. So I can write something like type Example = Something[Example] (Yes, this is useful.) * Type checking and compile-time computation can interact in interesting ways. Does type checking take place before compile-time code runs, after it runs, or can they be interleaved? Different choices give different trade-offs. It's not clear to me what Zig does and hence what tradeoffs it makes. * The article suggests that compile-time code can generate code (not just values) but doesn't discuss hygiene. There is a good discussion of some issues here: https://typesanitizer.com/blog/zig-generics.html https://typesanitizer.com/blog/zig-generics.html

flohofwoe 2y ago
I think most of those points one only stumbles over after a few thousand lines of Zig and going really deep into the comptime features. And some features in your list are of questionable value IMHO (e.g. the "reasoning over a function type signature" - Rust could be a much more ergonomic language if the compiler wouldn't have to rely on function signatures alone but instead could peek into called function bodies). There are definitely some tradeoffs in Zig's comptime system, but I think the more important point is that nothing about it is surprising when working with it, it's only when coming from languages like Rust or C++ where Zig's comptime, generics and reflection might look 'weird'.
- eptcyka 2y ago
  > Rust could be a much more ergonomic language if the compiler wouldn't have to rely on function signatures alone but instead could peek into called function bodies This path leads to unbounded runtime for the type checker/borrow checker. We’re not happy about build times as is.
  - littlestymaar 2y ago
    And also lead to subtle errors for users of crates. Semver is hard enough to do when the compiler only deals with signatures, but if the body of the functions now contain invariants that can be relied on by function callers then it becomes intractable.
- lmm 2y ago
  > most of those points one only stumbles over after a few thousand lines of Zig and going really deep into the comptime features. > nothing about it is surprising when working with it I think there's a contradiction here - when you get deep into using this kind of feature in a complex way is precisely when you most need it to behave consistently, and tends to be where this kind of ad-hoc approach breaks down.
  - throwawaymaths 2y ago
    if youve never gone deep into zig comptime... really nothing is surprising, except possibly when you can't do things and usually after a bit of thinking about it you understand why you can't.
marhee 2y ago
Interesting points. > Implementing generics in this way breaks parametricity. Simply put, parametricity means being able to reason about functions just from their type signature. You can't do this when the function can do arbitrary computation based on the concrete type a generic type is instantiated with. Do you mean reasoning about a function in the sense of just understanding what a functions does (or can do), i.e. in the view of the practical programmer, or reasoning about the function in a typed theoretical system (e.g. typed lambda calculus or maybe even more exotic)? Or maybe a bit of both? There is certainly a concern from the theoretical viewpoint but how important is that for a practical programming language? For example, I believe C++ template programming also breaks "parametricity" by supporting template specialisation. While there are many mundane issues with C++ templates, breaking parametricity is not a very big deal in practice. In contrast, it enables optimisations that are not otherwise possible (for templates). Consider for example std::vector<bool>: implementations can be made that actually store a single bit per vector element (instead of how a bool normally is represented using an int or char). Maybe this is even required by the standard, I don't recall. My point is that in makes sense for C++ to allow this, I think.
- SkiFire13 2y ago
  > For example, I believe C++ template programming also breaks "parametricity" by supporting template specialisation. C++ breaks parametricity even with normal templates, since you can e.g. call a method that exists/is valid only on some instantiations of the template. The issue is that the compiler can't help you check whether your template type checks or not, you will only figure out when you instantiate it with a concrete type. Things get worse when you call a templated function from within another templated function, since the error can then be arbitrarily levels deep. > My point is that in makes sense for C++ to allow this, I think. Whether it makes sense or not it's a big pain point and some are trying to move away from it (see e.g. Carbon's approach to generics)
  - marhee 2y ago
    > C++ breaks parametricity even with normal templates I might be wrong here, but as I understand it "parametricity" means loosely that all instantiations use the same function body. To quote wikipedia: "parametricity is an abstract uniformity property enjoyed by parametrically polymorphic functions, which captures the intuition that all instances of a polymorphic function act the same way" In this view, C++ does not break parametricity with "normal" (i.e. non-specialised) templates. Of course, C++ does not type check a template body against its parameters (unless concepts/trairs are used), leading to the problems you describe, but it's a different thing as far as I understand.
medo-bear 2y ago
> Lisps don't have a type system, which makes things a bit more complicated SBCL, which is a very popular Common Lisp implementation, is indeed strongly typed. Coalton, which is an addon, is even statically typed
- gjm11 2y ago
  medo-bear, you might want to know that you appear to be shadowbanned -- all your comments for the last ~10 days are dead. (I have some plausible guesses at what provoked this, though I have to say that I didn't see anything that looks to me like sufficient justification.) (I "vouched" for your comment to which this is a reply, and that seems to have been sufficient to un-dead it. Unless the system's set up so that vouching for a shadowbanned comment un-deads it only for the person who does the vouching, I guess...)
  - medo-bear 2y ago
    Thanks
anonymoushn 2y ago
> type Example = Something[Example] You can't use the binding early like this, but inside of the type definition you can use the @This() builtin to get a value that's the type you're in, and you can presumably do whatever you like with it. The type system barely does anything, so it's not very interesting when type checking runs. comptime code is type checked and executed. Normal code is typechecked and not executed. comptime is not a macro system. It doesn't have the ability to be unhygienic. It can cleverly monomorphize code, or it can unroll code, or it can omit code, but I don't think it can generate code.
- shakna 2y ago
  Until version 0.12.0 (April 2024), you could make arbitrary syscalls, allowing you to generate code at comptime, and promote vars between comptime and runtime. [0] Before then, you could do some rather funky things with pointers and memory, and was very much not hygienic. [0] https://ziglang.org/download/0.12.0/release-notes.html#Comptime-Memory-Changes https://ziglang.org/download/0.12.0/release-notes.html#Compt...
ScottRedig 2y ago
Hi, article author here. I was motivated to write this post after having trouble articulating some of its points while at a meetup, so that's why the goal of this post was focused on explaining things, and not being critical. So at least address your points here: * I do agree this is a direct trade-off with Zig style comptime, versus more statically defined function signatures. I don't think this affects all code, only code which does such reasoning with types, so it's a trade-off between reasoning and expressivity that you can make depending on your needs. On the other hand, per the post's view 0, I have found that just going in and reading the source code easily answers the questions I have when the type signature doesn't. I don't think I've ever been confused about how to use something for more than the time it takes to read a few dozen lines of code. * Your specific example for recursive generic types poses a problem because a name being used in the declaration causes a "dependency loop detected" error. There are ways around this. The generics example in the post for example references itself. If you had a concrete example showing a case where this does something, I could perhaps show you the zig code that does it. * Type checking happens during comptime. Eg, this code: pub fn main() void { @compileLog("Hi"); const a: u32 = "42"; _ = a; @compileLog("Bye"); } Gives this error: when_typecheck.zig:3:17: error: expected type 'u32', found '*const [2:0]u8' const a: u32 = "42"; ^~~~ Compile Log Output: @as(*const [2:0]u8, "Hi") So the first @compileLog statement was run by comptime, but then the type check error stopped it from continuing to the second @compileLog statement. If you dig into the Zig issues, there are some subtle ways the type checking between comptime and runtime can cause problems. However it takes some pretty esoteric code to hit them, and they're easily resolved. Also, they're well known by the core team and I expect them to be addressed before 1.0. * I'm not sure what you mean by hygiene, can you elaborate?
- mananaysiempre 2y ago
  “Hygiene” in the context of macro systems refers to the user’s code and the macro’s inserted code being unable to capture each other’s variables (either at all or without explicit action on part of the macro author). If, say, you’re writing a macro and your generated code declares a variable called ‘x’ for its own purposes, you most probably don’t want that variable to interfere with a chunk of user’s code you received that uses an ‘x’ from an enclosing scope, even if naïvely the user’s ‘x’ is shadowed by the macro’s ‘x’ at the insertion point of the chunk. It’s possible but tedious and error-prone to avoid this problem by hand by generating unique identifier names for all macro-defined runtime variables (this usually goes by the Lisp name GENSYM). But what you actually want, arguably, is an extended notion of lexical scope where it also applies to the macro’s text and macro user’s program as written instead of the macroexpanded output, so the macro’s and user’s variables can’t interfere with each other simply because they appear in completely different places of the program—again, as written, not as macroexpanded. That’s possible to implement, and many Scheme implementations do it for example, but it’s tricky. And it becomes less clear-cut what this even means when the macro is allowed to peer into the user’s code and change pieces inside. (Sorry for the lack of examples; I don’t know enough to write one in Zig, and I’m not sure giving one in Scheme would be helpful.)
withoutboats3 2y ago
100%. So tiring that the discourse around this is based on 15 minute demos and not actual understandings of the trade offs. Varun Gandhi's post that you link to is great. Based on my experience with Rust, a lot of what people want to do with its "constant generics" probably would be easier to do with a feature like comptime. Letting you do math on constant generics while maintaining parametricity is hard to implement, and when all you really want is "a trait for a hash function with an output size of N," probably giving up parametricity for that purpose and generating the trait from N as an earlier codegen step is fine for you, but Rust's macros are too flexible and annoying for doing it that way. But as soon as you replace parametric polymorphism with a naive code generation feature, you're in for a world of hurt.
lerno 2y ago
I find that the hard part with designing macros and other metaprogramming constructs that run at compile time is not adding POWER - that part is easy, but to make it readable and easy to understand. If a reader of the code needs to stop to work out the code then that is a weakness, not a strength - as such a pause in code reading affects everything from refactoring to spotting bugs. In Zig, compile time code looks like runtime code and you cannot easily know which is which without looking up the definition of the variables. Turning some statements into compile time, like for, requires ”inline” while some, like if, always folds at compile time if it is constant resolved, skipping even semantic checking of the ”dead” branch. Grasping this at a glance is very challenging. There is also the issue of generating types - and not just values - at compile time. This means that a tool refactoring a compile time defined struct member must know how that struct member was created - which may be through arbitrary code execution. All of this, and including ”build.zig”- the build tool describing how to compile a project using code invocations, makes it extremely challenging for an IDE to reason about code and provide meaningful analysis and refactoring tools. Which also in the end may affect overall code quality. So it’s a trade-off. For a contrast, look at C3 which has a comparable amount of compile time but tries to be IDE friendly.
miki123211 2y ago
And I would add: * Documentation. In a sufficiently-powerful comptime system, you can write a function that takes in a path to a .proto file and returns the types defined in that file. How should this function be documented? What happens when you click a reference to such a generated type in the documentation viewer? * IDE autocompletions, go to definition, type hinting etc. A similar problem, especially when you're working on some half-written code and actual compilation isn't possible yet.
- adonovan 2y ago
  Also: security. Does this feature imply that merely building someone else’s program executes their code on your machine?
  - mpalmer 2y ago
    Syscalls aren't available to comptime code
    - actionfromafar 2y ago
      Also see e.g. https://github.com/rust-lang/rust-analyzer/issues/14375 https://github.com/rust-lang/rust-analyzer/issues/14375
  - badsectoracula 2y ago
    Considering that pretty much every non-toy project isn't built by directly calling the compiler but through build tools like make, cmake, autotools, etc or even scripts like `build.sh` that can call arbitrary commands and that even IDEs have functionality to let you call arbitrary commands before and after builds (and had since the 90s at least), i do not see this as a realistic concern worth of limiting a language's functionality.
    - adonovan 2y ago
      Just because most projects’ builds have large attack surfaces doesn’t mean we should accept that. The build and IDE tooling for Go does not trust the code it consumes.
MathMonkeyMan 2y ago
Scheme has a "hygienic" macro system that allows you to do arbitrary computation and code alteration at compile time. The language doesn't see wide adoption in industry, so maybe its most important lessons have yet to be learned, but one problem with meta-programming is that it turns part of your program into a compiler. This happens to an extent in every language. When you're writing a library, you're solving the problem "I want users to be able to write THIS and have it be the same as if they had written THAT." A compiler. Meta-programming facilities just expand how different THIS and THAT can be. Understanding compilers is hard. So, that's at least one potential issue with compile-time programming.
- Validark 2y ago
  By your definition practically any code is a compiler unless you literally typed out every individual thing the machine should do, one by one. "Understanding compilers is hard." I think this is just unnecessarily pessimistic or embracing incompetence as the norm. It's really not hard to understand the concept of an "inline" loop. And so what if I do write a compiler so that when I do `print("%d", x)` it just gives me a piece of code that converts `x` to a "digit" number and doesn't include float handling? That's not hard to understand.
jmull 2y ago
> being able to reason about functions just from their type signature. This has nothing to do with compile-time execution, though. You can reason about a function from its declaration if it has a clear logical purpose, is well named, and has well named parameters. You can consider any part of a parameter the programmer can specify as part of the name, including label, type name, etc. > There is a good discussion of some issues here: https://typesanitizer.com/blog/zig-generics.html https://typesanitizer.com/blog/zig-generics.html That's actually not a great article. While I agree with the conclusion stated in the title, it's a kind of "debate team" approach to argumentation which tries to win points rather than make meaningful arguments. The better way to frame the debate is flexibility vs complexity. A fixed function generics system in a language is simpler (if well designed) than a programmable one, but less flexible. The more flexibility you give a generics system, the more complex it becomes, and the closer it becomes to a programming language in its own right. The nice thing about zig's approach is that the meta-programming language is practically the same thing as the regular programming language (which, itself, is a simple language). That minimizes the incremental complexity cost. It does introduce an extra complexity though: it's harder for the programmer to keep straight what code is executing at compile time vs runtime because the code is interleaved and the context clues are minimal. I wonder if a "comptime shader" could be added to the language server/editor plugin that puts a different background color on comptime code.
- jasode 2y ago
  >You can _reason_ about a function from its declaration if it has a clear logical purpose, is well named, and has well named parameters. I think "reason" in gp's context is "compile-time reasoning" as in the compiler's deterministic algorithm to parse the code and assign properties etc. This has downstream effects with generating compiler errors, etc. It's not about the human programmer's ability to reason so any "improved naming" of function names or parameters still won't help the compiler out because it's still just an arbitrary "symbol" in the eyes of the parser.
  - jmull 2y ago
    Downstream effects with generating compiler errors is still about the human programmer's ability to reason about the code, and error messages can only reference the identifier names provided. The compiler doesn't do anything you, the programmer, don't tell it to do. You tell it what to do by writing code using a certain syntax, connecting identifiers, keywords, and symbols. That's it. If the meaning isn't in the identifiers you provide and how you connect them together with keywords and symbols, it isn't in there at all. The compiler doesn't care what identifier names you use, but that's true whether the identifier is for a parameter label, type name, function name or any other kind of name. The programmer gives those meaning to human readers by choosing meaningful names. Anyway, zig's compile errors seem OK to me so far. Actually, the zig comptime programmer can do better than a non-programmable compiler when it comes to error messages. You can detect arbitrary logical errors and provide your own compiler error messages.
MatthiasPortzel 2y ago
I'm a pretty big fan of Zig--I've been following it and writing it on-and-off for a couple of years. I think that comptime has a couple of use-cases where it is very cool. Generics, initializing complex data-structures at compile-time, and target-specific code-generation are the big three where comptime shines. However, in other situations seeing "comptime" in Zig code has makes me go "oh no" because, like Lisp macros, it's very easy to use comptime to avoid a problem that doesn't exist or wouldn't exist if you structured other parts of your code better. For example, the OP's example of iterating the fields of a struct to sum the values is unfortunately characteristic of how people use comptime in the wild--when they would often be better served by using a data-structure that is actually iterable (e.g. std.enums.EnumArray).
- bunderbunder 2y ago
  This feels like it's it's a constant problem with all more advanced language features. I've had the same reaction to uses of lisp macros, C-style macros, Java compiler extensions, Ruby's method_missing, Python monkey patching, JavaScript prototype inheritance, monads, inheritance... Maybe the real WTF is the friends we made along the way. <3 <3 <3
  - arccy 2y ago
    this is why Go is so great....
    - bunderbunder 2y ago
      Go is not immune. See: interface pollution.
    - 9rx 2y ago
      And why it draws so much dislike: It doesn't offer many ways to paper over poor design decisions.
    - paulddraper 2y ago
      If I had a dollar for every Go code generator
eddd-ddde 2y ago
C++ has so many complexities like SFINAE that I wouldn't say you are "able to reason about functions just from their type signature".
- gpderetta 2y ago
  C++ templates are not parametric by design.
hansvm 2y ago
> parametricity That feels like the wrong word for the thing you're describing. Linguistic arguments aside, yes, you're absolutely right. In Zig though, that issue is completely orthogonal to generics. The first implementation `foo` is the "only" option available for "truly arbitrary" `T` if you don't magic up some extra information from somewhere. The second implementation `bar` uses an extra language feature unrelated to generics to return a different valid value (it's valid so long as the result of `bar(T, x)` is never accessed). The third option `baz` works on any type with non-zero width and just clobbers some data for fun (you could golf it some more, but I think the 5-line implementation makes it easier to read for non-Zig programmers). Notice that we haven't performed a computation with `T` and were still able to do things that particular definition of parametricity would not approve of. fn foo(T: type, x: T) T { return x; } fn bar(T: type, x: T) T { _ = x; return undefined; } fn baz(T: type, x: T) T { var result: T = x; const result_ptr: *T = &result; const dangerous_shenanigans_ptr: *u8 = @ptrCast(result_ptr); dangerous_shenanigans_ptr.* = 42; return result; } Zig does give up that particular property (being able to rely on just a type signature to understand what's going on). Its model is closer to "compile-time duck-typing." The constraints on `T` aren't an explicitly enumerated list of constraints; they're an in vivo set of properties the code using `T` actually requires. That fact is extremely annoying from time to time (e.g., for one or two major releases the reference Reader/Writer didn't include the full set of methods, but all functions using readers and writers just took in an `anytype`, so implementers either had to read a lot of source or play a game of whack-a-mole with the compiler errors to find the true interface), but for most code it's really not hard to handle. E.g., if you've seen the `Iterator` pattern once, the following isn't all that hard to understand. Your constraints on `It` are that it tell you what the return type is, that return type ought to be some sort of non-comptime numeric, and it should have a `fn next(self: *It) ?T` method whose return values after the first `null` you're allowed to ignore. If you violate any of those constraints (except, perhaps, the last one -- maybe your iterator chooses to return null and then a few more values) then the code will fail at comptime. If you're afraid of excessive compiler error message lengths, you can use `@compileError()` to create a friendlier message documenting your constraints. It's a different pattern from what you're describing, but it's absolutely not hard to use correctly. fn sum(It: type, it: *It) It.T { var total: T = 0; while (it.next()) |item| total += item; return total; } > recursive generics A decent mental model (most of which follows from "view 4" in TFA, where the runtime code is the residue after the interpreter resolves everything it can at comptime) is treating types as immutable and treating comptime evaluation like an interpreted language. With that view, `type Example = Something[Example]` can't work because `Example` must be fully defined before you can pass it into `Something`. The laziness you see in ordinary non-generic type instantiations doesn't cross function boundaries. I'm not sure if there's a feature request for that (nothing obvious is standing out), but I'd be a fan @AndyKelley if you're interested. In terms of that causing problems IRL, it's only been annoying a few times in the last few years for me. The most recent one involved some comptime parser combinators, and there was a recursive message structure I wanted to handle. I worked around it by creating a concrete `FooParser` type with its associated manually implemented `parse` function (which itself was able to mostly call into rather than re-implement other parsers) instead of building up `FooParser` using combinators, so that the normal type instantiation laziness would work without issues. > when does type checking run Type inference is simplistic enough that this is almost a non-issue in Zig, aside from the normal tradeoffs from limited type inference (last I checked, they plan to keep it that way because it's not very important to them, it actively hinders the goal of being able to understand code by looking at a local snapshot, and that sort of complexity and constraint might keep the project from hitting more important goals like incremental compilation and binary editing). They are interleaved though (at least in the observable behavior, if you treat comptime execution as an interpreter).
tliltocatl 2y ago
Parametricity is a neat trick for mathematicians, it's not really worth it in a low-level language (not least because the type system is badly unsound anyway).
moonlion_eth 2y ago
I think the reason people are so in love with zig comptime is because even rust lovers realize that rust macros are a pile of poo poo
naasking 2y ago
You often want parametricity, until you want type-specific behaviour, which is very, very common. Haskell uses this to great effect with type classes.

flohofwoe 2y ago

I think most of those points one only stumbles over after a few thousand lines of Zig and going really deep into the comptime features. And some features in your list are of questionable value IMHO (e.g. the "reasoning over a function type signature" - Rust could be a much more ergonomic language if the compiler wouldn't have to rely on function signatures alone but instead could peek into called function bodies). There are definitely some tradeoffs in Zig's comptime system, but I think the more important point is that nothing about it is surprising when working with it, it's only when coming from languages like Rust or C++ where Zig's comptime, generics and reflection might look 'weird'.

eptcyka 2y ago
> Rust could be a much more ergonomic language if the compiler wouldn't have to rely on function signatures alone but instead could peek into called function bodies This path leads to unbounded runtime for the type checker/borrow checker. We’re not happy about build times as is.
- littlestymaar 2y ago
  And also lead to subtle errors for users of crates. Semver is hard enough to do when the compiler only deals with signatures, but if the body of the functions now contain invariants that can be relied on by function callers then it becomes intractable.
lmm 2y ago
> most of those points one only stumbles over after a few thousand lines of Zig and going really deep into the comptime features. > nothing about it is surprising when working with it I think there's a contradiction here - when you get deep into using this kind of feature in a complex way is precisely when you most need it to behave consistently, and tends to be where this kind of ad-hoc approach breaks down.
- throwawaymaths 2y ago
  if youve never gone deep into zig comptime... really nothing is surprising, except possibly when you can't do things and usually after a bit of thinking about it you understand why you can't.

marhee 2y ago

Interesting points. > Implementing generics in this way breaks parametricity. Simply put, parametricity means being able to reason about functions just from their type signature. You can't do this when the function can do arbitrary computation based on the concrete type a generic type is instantiated with. Do you mean reasoning about a function in the sense of just understanding what a functions does (or can do), i.e. in the view of the practical programmer, or reasoning about the function in a typed theoretical system (e.g. typed lambda calculus or maybe even more exotic)? Or maybe a bit of both? There is certainly a concern from the theoretical viewpoint but how important is that for a practical programming language? For example, I believe C++ template programming also breaks "parametricity" by supporting template specialisation. While there are many mundane issues with C++ templates, breaking parametricity is not a very big deal in practice. In contrast, it enables optimisations that are not otherwise possible (for templates). Consider for example std::vector<bool>: implementations can be made that actually store a single bit per vector element (instead of how a bool normally is represented using an int or char). Maybe this is even required by the standard, I don't recall. My point is that in makes sense for C++ to allow this, I think.

SkiFire13 2y ago
> For example, I believe C++ template programming also breaks "parametricity" by supporting template specialisation. C++ breaks parametricity even with normal templates, since you can e.g. call a method that exists/is valid only on some instantiations of the template. The issue is that the compiler can't help you check whether your template type checks or not, you will only figure out when you instantiate it with a concrete type. Things get worse when you call a templated function from within another templated function, since the error can then be arbitrarily levels deep. > My point is that in makes sense for C++ to allow this, I think. Whether it makes sense or not it's a big pain point and some are trying to move away from it (see e.g. Carbon's approach to generics)
- marhee 2y ago
  > C++ breaks parametricity even with normal templates I might be wrong here, but as I understand it "parametricity" means loosely that all instantiations use the same function body. To quote wikipedia: "parametricity is an abstract uniformity property enjoyed by parametrically polymorphic functions, which captures the intuition that all instances of a polymorphic function act the same way" In this view, C++ does not break parametricity with "normal" (i.e. non-specialised) templates. Of course, C++ does not type check a template body against its parameters (unless concepts/trairs are used), leading to the problems you describe, but it's a different thing as far as I understand.

medo-bear 2y ago

> Lisps don't have a type system, which makes things a bit more complicated SBCL, which is a very popular Common Lisp implementation, is indeed strongly typed. Coalton, which is an addon, is even statically typed

gjm11 2y ago
medo-bear, you might want to know that you appear to be shadowbanned -- all your comments for the last ~10 days are dead. (I have some plausible guesses at what provoked this, though I have to say that I didn't see anything that looks to me like sufficient justification.) (I "vouched" for your comment to which this is a reply, and that seems to have been sufficient to un-dead it. Unless the system's set up so that vouching for a shadowbanned comment un-deads it only for the person who does the vouching, I guess...)
- medo-bear 2y ago
  Thanks

anonymoushn 2y ago

> type Example = Something[Example] You can't use the binding early like this, but inside of the type definition you can use the @This() builtin to get a value that's the type you're in, and you can presumably do whatever you like with it. The type system barely does anything, so it's not very interesting when type checking runs. comptime code is type checked and executed. Normal code is typechecked and not executed. comptime is not a macro system. It doesn't have the ability to be unhygienic. It can cleverly monomorphize code, or it can unroll code, or it can omit code, but I don't think it can generate code.

shakna 2y ago
Until version 0.12.0 (April 2024), you could make arbitrary syscalls, allowing you to generate code at comptime, and promote vars between comptime and runtime. [0] Before then, you could do some rather funky things with pointers and memory, and was very much not hygienic. [0] https://ziglang.org/download/0.12.0/release-notes.html#Comptime-Memory-Changes https://ziglang.org/download/0.12.0/release-notes.html#Compt...

ScottRedig 2y ago

Hi, article author here. I was motivated to write this post after having trouble articulating some of its points while at a meetup, so that's why the goal of this post was focused on explaining things, and not being critical. So at least address your points here: * I do agree this is a direct trade-off with Zig style comptime, versus more statically defined function signatures. I don't think this affects all code, only code which does such reasoning with types, so it's a trade-off between reasoning and expressivity that you can make depending on your needs. On the other hand, per the post's view 0, I have found that just going in and reading the source code easily answers the questions I have when the type signature doesn't. I don't think I've ever been confused about how to use something for more than the time it takes to read a few dozen lines of code. * Your specific example for recursive generic types poses a problem because a name being used in the declaration causes a "dependency loop detected" error. There are ways around this. The generics example in the post for example references itself. If you had a concrete example showing a case where this does something, I could perhaps show you the zig code that does it. * Type checking happens during comptime. Eg, this code: pub fn main() void { @compileLog("Hi"); const a: u32 = "42"; _ = a; @compileLog("Bye"); } Gives this error: when_typecheck.zig:3:17: error: expected type 'u32', found '*const [2:0]u8' const a: u32 = "42"; ^~~~ Compile Log Output: @as(*const [2:0]u8, "Hi") So the first @compileLog statement was run by comptime, but then the type check error stopped it from continuing to the second @compileLog statement. If you dig into the Zig issues, there are some subtle ways the type checking between comptime and runtime can cause problems. However it takes some pretty esoteric code to hit them, and they're easily resolved. Also, they're well known by the core team and I expect them to be addressed before 1.0. * I'm not sure what you mean by hygiene, can you elaborate?

mananaysiempre 2y ago
“Hygiene” in the context of macro systems refers to the user’s code and the macro’s inserted code being unable to capture each other’s variables (either at all or without explicit action on part of the macro author). If, say, you’re writing a macro and your generated code declares a variable called ‘x’ for its own purposes, you most probably don’t want that variable to interfere with a chunk of user’s code you received that uses an ‘x’ from an enclosing scope, even if naïvely the user’s ‘x’ is shadowed by the macro’s ‘x’ at the insertion point of the chunk. It’s possible but tedious and error-prone to avoid this problem by hand by generating unique identifier names for all macro-defined runtime variables (this usually goes by the Lisp name GENSYM). But what you actually want, arguably, is an extended notion of lexical scope where it also applies to the macro’s text and macro user’s program as written instead of the macroexpanded output, so the macro’s and user’s variables can’t interfere with each other simply because they appear in completely different places of the program—again, as written, not as macroexpanded. That’s possible to implement, and many Scheme implementations do it for example, but it’s tricky. And it becomes less clear-cut what this even means when the macro is allowed to peer into the user’s code and change pieces inside. (Sorry for the lack of examples; I don’t know enough to write one in Zig, and I’m not sure giving one in Scheme would be helpful.)

withoutboats3 2y ago

100%. So tiring that the discourse around this is based on 15 minute demos and not actual understandings of the trade offs. Varun Gandhi's post that you link to is great. Based on my experience with Rust, a lot of what people want to do with its "constant generics" probably would be easier to do with a feature like comptime. Letting you do math on constant generics while maintaining parametricity is hard to implement, and when all you really want is "a trait for a hash function with an output size of N," probably giving up parametricity for that purpose and generating the trait from N as an earlier codegen step is fine for you, but Rust's macros are too flexible and annoying for doing it that way. But as soon as you replace parametric polymorphism with a naive code generation feature, you're in for a world of hurt.

lerno 2y ago

I find that the hard part with designing macros and other metaprogramming constructs that run at compile time is not adding POWER - that part is easy, but to make it readable and easy to understand. If a reader of the code needs to stop to work out the code then that is a weakness, not a strength - as such a pause in code reading affects everything from refactoring to spotting bugs. In Zig, compile time code looks like runtime code and you cannot easily know which is which without looking up the definition of the variables. Turning some statements into compile time, like for, requires ”inline” while some, like if, always folds at compile time if it is constant resolved, skipping even semantic checking of the ”dead” branch. Grasping this at a glance is very challenging. There is also the issue of generating types - and not just values - at compile time. This means that a tool refactoring a compile time defined struct member must know how that struct member was created - which may be through arbitrary code execution. All of this, and including ”build.zig”- the build tool describing how to compile a project using code invocations, makes it extremely challenging for an IDE to reason about code and provide meaningful analysis and refactoring tools. Which also in the end may affect overall code quality. So it’s a trade-off. For a contrast, look at C3 which has a comparable amount of compile time but tries to be IDE friendly.

miki123211 2y ago

And I would add: * Documentation. In a sufficiently-powerful comptime system, you can write a function that takes in a path to a .proto file and returns the types defined in that file. How should this function be documented? What happens when you click a reference to such a generated type in the documentation viewer? * IDE autocompletions, go to definition, type hinting etc. A similar problem, especially when you're working on some half-written code and actual compilation isn't possible yet.

adonovan 2y ago
Also: security. Does this feature imply that merely building someone else’s program executes their code on your machine?
- mpalmer 2y ago
  Syscalls aren't available to comptime code
  - actionfromafar 2y ago
    Also see e.g. https://github.com/rust-lang/rust-analyzer/issues/14375 https://github.com/rust-lang/rust-analyzer/issues/14375
- badsectoracula 2y ago
  Considering that pretty much every non-toy project isn't built by directly calling the compiler but through build tools like make, cmake, autotools, etc or even scripts like `build.sh` that can call arbitrary commands and that even IDEs have functionality to let you call arbitrary commands before and after builds (and had since the 90s at least), i do not see this as a realistic concern worth of limiting a language's functionality.
  - adonovan 2y ago
    Just because most projects’ builds have large attack surfaces doesn’t mean we should accept that. The build and IDE tooling for Go does not trust the code it consumes.

MathMonkeyMan 2y ago

Scheme has a "hygienic" macro system that allows you to do arbitrary computation and code alteration at compile time. The language doesn't see wide adoption in industry, so maybe its most important lessons have yet to be learned, but one problem with meta-programming is that it turns part of your program into a compiler. This happens to an extent in every language. When you're writing a library, you're solving the problem "I want users to be able to write THIS and have it be the same as if they had written THAT." A compiler. Meta-programming facilities just expand how different THIS and THAT can be. Understanding compilers is hard. So, that's at least one potential issue with compile-time programming.

Validark 2y ago
By your definition practically any code is a compiler unless you literally typed out every individual thing the machine should do, one by one. "Understanding compilers is hard." I think this is just unnecessarily pessimistic or embracing incompetence as the norm. It's really not hard to understand the concept of an "inline" loop. And so what if I do write a compiler so that when I do `print("%d", x)` it just gives me a piece of code that converts `x` to a "digit" number and doesn't include float handling? That's not hard to understand.

jmull 2y ago

> being able to reason about functions just from their type signature. This has nothing to do with compile-time execution, though. You can reason about a function from its declaration if it has a clear logical purpose, is well named, and has well named parameters. You can consider any part of a parameter the programmer can specify as part of the name, including label, type name, etc. > There is a good discussion of some issues here: https://typesanitizer.com/blog/zig-generics.html https://typesanitizer.com/blog/zig-generics.html That's actually not a great article. While I agree with the conclusion stated in the title, it's a kind of "debate team" approach to argumentation which tries to win points rather than make meaningful arguments. The better way to frame the debate is flexibility vs complexity. A fixed function generics system in a language is simpler (if well designed) than a programmable one, but less flexible. The more flexibility you give a generics system, the more complex it becomes, and the closer it becomes to a programming language in its own right. The nice thing about zig's approach is that the meta-programming language is practically the same thing as the regular programming language (which, itself, is a simple language). That minimizes the incremental complexity cost. It does introduce an extra complexity though: it's harder for the programmer to keep straight what code is executing at compile time vs runtime because the code is interleaved and the context clues are minimal. I wonder if a "comptime shader" could be added to the language server/editor plugin that puts a different background color on comptime code.

jasode 2y ago
>You can _reason_ about a function from its declaration if it has a clear logical purpose, is well named, and has well named parameters. I think "reason" in gp's context is "compile-time reasoning" as in the compiler's deterministic algorithm to parse the code and assign properties etc. This has downstream effects with generating compiler errors, etc. It's not about the human programmer's ability to reason so any "improved naming" of function names or parameters still won't help the compiler out because it's still just an arbitrary "symbol" in the eyes of the parser.
- jmull 2y ago
  Downstream effects with generating compiler errors is still about the human programmer's ability to reason about the code, and error messages can only reference the identifier names provided. The compiler doesn't do anything you, the programmer, don't tell it to do. You tell it what to do by writing code using a certain syntax, connecting identifiers, keywords, and symbols. That's it. If the meaning isn't in the identifiers you provide and how you connect them together with keywords and symbols, it isn't in there at all. The compiler doesn't care what identifier names you use, but that's true whether the identifier is for a parameter label, type name, function name or any other kind of name. The programmer gives those meaning to human readers by choosing meaningful names. Anyway, zig's compile errors seem OK to me so far. Actually, the zig comptime programmer can do better than a non-programmable compiler when it comes to error messages. You can detect arbitrary logical errors and provide your own compiler error messages.

MatthiasPortzel 2y ago

I'm a pretty big fan of Zig--I've been following it and writing it on-and-off for a couple of years. I think that comptime has a couple of use-cases where it is very cool. Generics, initializing complex data-structures at compile-time, and target-specific code-generation are the big three where comptime shines. However, in other situations seeing "comptime" in Zig code has makes me go "oh no" because, like Lisp macros, it's very easy to use comptime to avoid a problem that doesn't exist or wouldn't exist if you structured other parts of your code better. For example, the OP's example of iterating the fields of a struct to sum the values is unfortunately characteristic of how people use comptime in the wild--when they would often be better served by using a data-structure that is actually iterable (e.g. std.enums.EnumArray).

bunderbunder 2y ago
This feels like it's it's a constant problem with all more advanced language features. I've had the same reaction to uses of lisp macros, C-style macros, Java compiler extensions, Ruby's method_missing, Python monkey patching, JavaScript prototype inheritance, monads, inheritance... Maybe the real WTF is the friends we made along the way. <3 <3 <3
- arccy 2y ago
  this is why Go is so great....
  - bunderbunder 2y ago
    Go is not immune. See: interface pollution.
  - 9rx 2y ago
    And why it draws so much dislike: It doesn't offer many ways to paper over poor design decisions.
  - paulddraper 2y ago
    If I had a dollar for every Go code generator

eddd-ddde 2y ago

C++ has so many complexities like SFINAE that I wouldn't say you are "able to reason about functions just from their type signature".

gpderetta 2y ago
C++ templates are not parametric by design.

hansvm 2y ago

> parametricity That feels like the wrong word for the thing you're describing. Linguistic arguments aside, yes, you're absolutely right. In Zig though, that issue is completely orthogonal to generics. The first implementation `foo` is the "only" option available for "truly arbitrary" `T` if you don't magic up some extra information from somewhere. The second implementation `bar` uses an extra language feature unrelated to generics to return a different valid value (it's valid so long as the result of `bar(T, x)` is never accessed). The third option `baz` works on any type with non-zero width and just clobbers some data for fun (you could golf it some more, but I think the 5-line implementation makes it easier to read for non-Zig programmers). Notice that we haven't performed a computation with `T` and were still able to do things that particular definition of parametricity would not approve of. fn foo(T: type, x: T) T { return x; } fn bar(T: type, x: T) T { _ = x; return undefined; } fn baz(T: type, x: T) T { var result: T = x; const result_ptr: *T = &result; const dangerous_shenanigans_ptr: *u8 = @ptrCast(result_ptr); dangerous_shenanigans_ptr.* = 42; return result; } Zig does give up that particular property (being able to rely on just a type signature to understand what's going on). Its model is closer to "compile-time duck-typing." The constraints on `T` aren't an explicitly enumerated list of constraints; they're an in vivo set of properties the code using `T` actually requires. That fact is extremely annoying from time to time (e.g., for one or two major releases the reference Reader/Writer didn't include the full set of methods, but all functions using readers and writers just took in an `anytype`, so implementers either had to read a lot of source or play a game of whack-a-mole with the compiler errors to find the true interface), but for most code it's really not hard to handle. E.g., if you've seen the `Iterator` pattern once, the following isn't all that hard to understand. Your constraints on `It` are that it tell you what the return type is, that return type ought to be some sort of non-comptime numeric, and it should have a `fn next(self: *It) ?T` method whose return values after the first `null` you're allowed to ignore. If you violate any of those constraints (except, perhaps, the last one -- maybe your iterator chooses to return null and then a few more values) then the code will fail at comptime. If you're afraid of excessive compiler error message lengths, you can use `@compileError()` to create a friendlier message documenting your constraints. It's a different pattern from what you're describing, but it's absolutely not hard to use correctly. fn sum(It: type, it: *It) It.T { var total: T = 0; while (it.next()) |item| total += item; return total; } > recursive generics A decent mental model (most of which follows from "view 4" in TFA, where the runtime code is the residue after the interpreter resolves everything it can at comptime) is treating types as immutable and treating comptime evaluation like an interpreted language. With that view, `type Example = Something[Example]` can't work because `Example` must be fully defined before you can pass it into `Something`. The laziness you see in ordinary non-generic type instantiations doesn't cross function boundaries. I'm not sure if there's a feature request for that (nothing obvious is standing out), but I'd be a fan @AndyKelley if you're interested. In terms of that causing problems IRL, it's only been annoying a few times in the last few years for me. The most recent one involved some comptime parser combinators, and there was a recursive message structure I wanted to handle. I worked around it by creating a concrete `FooParser` type with its associated manually implemented `parse` function (which itself was able to mostly call into rather than re-implement other parsers) instead of building up `FooParser` using combinators, so that the normal type instantiation laziness would work without issues. > when does type checking run Type inference is simplistic enough that this is almost a non-issue in Zig, aside from the normal tradeoffs from limited type inference (last I checked, they plan to keep it that way because it's not very important to them, it actively hinders the goal of being able to understand code by looking at a local snapshot, and that sort of complexity and constraint might keep the project from hitting more important goals like incremental compilation and binary editing). They are interleaved though (at least in the observable behavior, if you treat comptime execution as an interpreter).

tliltocatl 2y ago

Parametricity is a neat trick for mathematicians, it's not really worth it in a low-level language (not least because the type system is badly unsound anyway).

moonlion_eth 2y ago

I think the reason people are so in love with zig comptime is because even rust lovers realize that rust macros are a pile of poo poo

naasking 2y ago

You often want parametricity, until you want type-specific behaviour, which is very, very common. Haskell uses this to great effect with type classes.