4 ms·

> Comptime's lazyness is a necessary feature and not an accident. This is how Zig can avoid having a macro system. Can you elaborate on lazy analysis replacing

by aarchi 6y ago

> Comptime's lazyness is a necessary feature and not an accident. This is how Zig can avoid having a macro system. Can you elaborate on lazy analysis replacing the need for macros?

Quekid5 6y ago
I'd appreciate some elaboration on that too. It sounds vaguely similar to SFINAE in C++, but I don't know enough about Zig's compilation model to know for sure. (I'm vaguely familar with Zig from a talk by the creator about 1½ years ago, fwiw.)
defen 6y ago
C macros are lazy, but they also operate at the level of lexical tokens instead of the AST, which means you can use macros to generate C code, but you can't really do it in a way that is guaranteed to be safe. With Zig you can have a function where some or all arguments are marked as "comptime", which means the values for those arguments must be known at compile time. Combined with the fact that types can be used as values at compile time means that you can use Zig to generate Zig functions in a safe way.
dralley 6y ago
https://www.youtube.com/watch?v=Gv2I7qTux7g&t=17m10s https://www.youtube.com/watch?v=Gv2I7qTux7g&t=17m10s
kristoff_it 6y ago
Lazyness is what allows you to write code that feels naturally coherent but that would be an error with eager analysis. As an example: switch(build.target.os) { .Linux => std.os.fork(), .Windows => std.os.funcUniqueToWindows(), else => @compileError("feature not supported for target os"), } This a simplified example to say that each path that depends on a comptime condition, such as the target OS, for example, feels intuitively consistent but in Zig types can (and do) mutate depending on those conditions and if the compiler were to eagerly check dead branches it would find plenty of semantical errors. In the stdlib you can see how `os` corresponds to a different struct definition depending on the target: https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L59-L76 https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L5...
- AndyKelley 6y ago
  This definitely does cause problems though; I want to acknowledge that. For example, right now we have an issue that auto-generated documentation does not include unreferenced globals. I have some ideas to address this, but it does represent a flaw in the status quo design of the language.
  - JacobCarlborg 6y ago
    In D, all semantic analysis is performed eagerly (I think), except for templates. D also supports CTFE (Compile Time Function Evaluation), `static if`, `static assert` and a few other language constructs that are evaluated at compile time. I experimented a bit at how D's documentation generator behaves using these language constructs. Here's a snippet of some D code: /// some struct description struct Foo(T) // template { /// some alias description alias Result = int; /// some method description Result foo() { string a = 3; // this does not normally compile } static if (is(T == int)) // evaluated at compile time { /// some method description 2 void bar() {} } version (Windows) { /// some method description for Windows void bazWindows() {} } else version (Posix) { /// some method description for Posix void bazPosix() {} } else static assert(false, "Unsupported platform"); // evaluated at compile time } When generating documentation for the above code, and `Foo` has not been instantiated, the generated docs will include `Foo`, `Result`, `foo`, `bar`, and `bazWindows`. This is regardless of platform. The return type of `foo` will be `Result` and not `int`. This clearly shows that the D compiler doesn't perform semantic analysis when generating documentation. When doing a regular compilation and `Foo` is instantiated, `bar` will only be included if `T` is an `int`. `bazWindows` will only be compiled on Windows and `bazPosix` will only be compiled on Posix platforms. Looking at the implementation, the compiler will generate the docs after semantic analysis and only if there are no errors. But, if `Foo` is never instantiated no errors have occurred so it will continue to generate the docs. On the other hand, if `Foo` is instantiated (and compiles) the compiler will generate docs for the AST after semantic analysis has been performed and `bazWindows` will only be included if the docs were generated on Windows and `bazPosix` will only be included on Posix platforms. What's weird though, is that it seems `bar` will be included regardless of what type `T` is.

by aarchi 6y ago

> Comptime's lazyness is a necessary feature and not an accident. This is how Zig can avoid having a macro system. Can you elaborate on lazy analysis replacing the need for macros?

Quekid5 6y ago

I'd appreciate some elaboration on that too. It sounds vaguely similar to SFINAE in C++, but I don't know enough about Zig's compilation model to know for sure. (I'm vaguely familar with Zig from a talk by the creator about 1½ years ago, fwiw.)

defen 6y ago

C macros are lazy, but they also operate at the level of lexical tokens instead of the AST, which means you can use macros to generate C code, but you can't really do it in a way that is guaranteed to be safe. With Zig you can have a function where some or all arguments are marked as "comptime", which means the values for those arguments must be known at compile time. Combined with the fact that types can be used as values at compile time means that you can use Zig to generate Zig functions in a safe way.

dralley 6y ago

https://www.youtube.com/watch?v=Gv2I7qTux7g&t=17m10s https://www.youtube.com/watch?v=Gv2I7qTux7g&t=17m10s

kristoff_it 6y ago

Lazyness is what allows you to write code that feels naturally coherent but that would be an error with eager analysis. As an example: switch(build.target.os) { .Linux => std.os.fork(), .Windows => std.os.funcUniqueToWindows(), else => @compileError("feature not supported for target os"), } This a simplified example to say that each path that depends on a comptime condition, such as the target OS, for example, feels intuitively consistent but in Zig types can (and do) mutate depending on those conditions and if the compiler were to eagerly check dead branches it would find plenty of semantical errors. In the stdlib you can see how `os` corresponds to a different struct definition depending on the target: https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L59-L76 https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L5...

AndyKelley 6y ago
This definitely does cause problems though; I want to acknowledge that. For example, right now we have an issue that auto-generated documentation does not include unreferenced globals. I have some ideas to address this, but it does represent a flaw in the status quo design of the language.
- JacobCarlborg 6y ago
  In D, all semantic analysis is performed eagerly (I think), except for templates. D also supports CTFE (Compile Time Function Evaluation), `static if`, `static assert` and a few other language constructs that are evaluated at compile time. I experimented a bit at how D's documentation generator behaves using these language constructs. Here's a snippet of some D code: /// some struct description struct Foo(T) // template { /// some alias description alias Result = int; /// some method description Result foo() { string a = 3; // this does not normally compile } static if (is(T == int)) // evaluated at compile time { /// some method description 2 void bar() {} } version (Windows) { /// some method description for Windows void bazWindows() {} } else version (Posix) { /// some method description for Posix void bazPosix() {} } else static assert(false, "Unsupported platform"); // evaluated at compile time } When generating documentation for the above code, and `Foo` has not been instantiated, the generated docs will include `Foo`, `Result`, `foo`, `bar`, and `bazWindows`. This is regardless of platform. The return type of `foo` will be `Result` and not `int`. This clearly shows that the D compiler doesn't perform semantic analysis when generating documentation. When doing a regular compilation and `Foo` is instantiated, `bar` will only be included if `T` is an `int`. `bazWindows` will only be compiled on Windows and `bazPosix` will only be compiled on Posix platforms. Looking at the implementation, the compiler will generate the docs after semantic analysis and only if there are no errors. But, if `Foo` is never instantiated no errors have occurred so it will continue to generate the docs. On the other hand, if `Foo` is instantiated (and compiles) the compiler will generate docs for the AST after semantic analysis has been performed and `bazWindows` will only be included if the docs were generated on Windows and `bazPosix` will only be included on Posix platforms. What's weird though, is that it seems `bar` will be included regardless of what type `T` is.