4 ms·

I did some experimenting recently and was disappointed by how limited it is. It's a great solution for generics but things like file access don't work in const

by flukus 4y ago

I did some experimenting recently and was disappointed by how limited it is. It's a great solution for generics but things like file access don't work in const expressions and the errors are horribly opaque with no hint that it's not allowed. I was hoping to be able to do things like generate type safe classes from a database schema but the current limitations mean you have to fall back to shell scripts, which zig-build also appears to not support. Even in this thread everyone is code golfing fizzbuzz instead of something more practical.

elcritch 4y ago
It's funny how something like Zig's comptime of C++'s constexpr get 90% of the way to solving most compile time issues, but can't knock out that last 10%. Compile time database types sound like one of those cases. F# had a feature for compile time types via "type providers". It seemed _really_ cool at first, but in practice is was a bit fragile. Though on the other hand I'm using compile Nim code to parse CMake files and provide static types for configuration values. It's super easy in Nim between macros and const's. Here's a ~170 lines of code where I'm compile time checking that my Nim code can compile time check against the current build configuration of Zephyr RTOS https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c/zconfs.nim https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c...
olodus 4y ago
Isn't that somewhat possible with @embedFile? Then you get the content of the file as a null terminated byte array / normal zig string. I would think you could do further comptime things to it after that no? I haven't tried it myself so maybe I am missing something. I get that this differs from normal file io, but I could argue that is in line with Zig motto of clarity. Also you would of course suddenly have to have the file content as part of your binary. Maybe you were hoping to be able to throw that away after you generated what you wanted...?
- flukus 4y ago
  In the case the file was only intended to be there for a temporary step, I wanted that working before involving the database, which I believe also won't work because you can't do system calls at comptime. Ultimately if you go down that path, whatever would be supplying the file could just as easily (or perhaps easier) be supplying zig code and you're still reliant on some sort of per-processor.

by flukus 4y ago

elcritch 4y ago

It's funny how something like Zig's comptime of C++'s constexpr get 90% of the way to solving most compile time issues, but can't knock out that last 10%. Compile time database types sound like one of those cases. F# had a feature for compile time types via "type providers". It seemed _really_ cool at first, but in practice is was a bit fragile. Though on the other hand I'm using compile Nim code to parse CMake files and provide static types for configuration values. It's super easy in Nim between macros and const's. Here's a ~170 lines of code where I'm compile time checking that my Nim code can compile time check against the current build configuration of Zephyr RTOS https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c/zconfs.nim https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c...

olodus 4y ago

Isn't that somewhat possible with @embedFile? Then you get the content of the file as a null terminated byte array / normal zig string. I would think you could do further comptime things to it after that no? I haven't tried it myself so maybe I am missing something. I get that this differs from normal file io, but I could argue that is in line with Zig motto of clarity. Also you would of course suddenly have to have the file content as part of your binary. Maybe you were hoping to be able to throw that away after you generated what you wanted...?

flukus 4y ago
In the case the file was only intended to be there for a temporary step, I wanted that working before involving the database, which I believe also won't work because you can't do system calls at comptime. Ultimately if you go down that path, whatever would be supplying the file could just as easily (or perhaps easier) be supplying zig code and you're still reliant on some sort of per-processor.