3 ms·

> If zig supports compiler hooks, then it could conceivably halt compilation unless these invariants are satisfied. Can you sketch out why hooks are necessary

> If zig supports compiler hooks, then it could conceivably halt compilation unless these invariants are satisfied. Can you sketch out why hooks are necessary on the proposals, like 14656 ? So far I have not read a justification, what the advantage of coupling it to the compiler provides as performance gains on concrete examples. Afaik, Rust has lifetime checks decoupled to parallelize compilation and I have not seen research or a list of the possible optimizations with synthetic benchmark results. > I'm not convinced that this needs to be in the type system. If you want to prevent static analysis semantics becoming an incompatibilty mess like C due to 1. unknown and 2. untrackable tag semantics, then you have to provide a at least an AST to ensure annotations have known + unique semantics as I explain in https://github.com/ziglang/zig/issues/14656#issuecomment-1437639789 https://github.com/ziglang/zig/issues/14656#issuecomment-143.... I would say that this is a primitive quasi-type check decoupled from main compilation and could be kept very flexible for research experiments by having an uri + multihash (so basically what Zig uses as package). More concretely: Stuff to look out for is RefinedC and related projects to have more strict C semantics + how to compose those things outside the regular Zig type system.

throwawaymaths 4y ago
The big advantage to coupling to the compiler is that it gives a tighter feedback loop for the developer, versus, say, statically checking as a part of CI, or forcing the dev to manually trigger static pass
- matu3ba 4y ago
  At some point you would have to choose for which analysis you want unless you force the analysis onto everybody. Which means adding it into the build system. Which means separate commands. The nice thing is that Zig conventions make things just work, because you could choose the command for your code base and third-party code would not need to care about your chosen build commands. The "binary lsp" will give the necessary info of what has changed etc, so the info is (eventually) incremental with minimal overhead (only ipc + optional network latency).
  - throwawaymaths 4y ago
    Why not support both? On the compiler side all it requires is a mechanism to register a subscription and publish to it. This is not terribly hard IMO.

throwawaymaths 4y ago

The big advantage to coupling to the compiler is that it gives a tighter feedback loop for the developer, versus, say, statically checking as a part of CI, or forcing the dev to manually trigger static pass

matu3ba 4y ago
At some point you would have to choose for which analysis you want unless you force the analysis onto everybody. Which means adding it into the build system. Which means separate commands. The nice thing is that Zig conventions make things just work, because you could choose the command for your code base and third-party code would not need to care about your chosen build commands. The "binary lsp" will give the necessary info of what has changed etc, so the info is (eventually) incremental with minimal overhead (only ipc + optional network latency).
- throwawaymaths 4y ago
  Why not support both? On the compiler side all it requires is a mechanism to register a subscription and publish to it. This is not terribly hard IMO.