Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things Zig comptime won't do

matklad.github.io

Post reply on HN
Print view View original

211–220 of 252 posts

Re: Things Zig comptime won't do

#211

Post by edflsafoiewq »

matklad wrote: post #206
pcwalton wrote: post #201

Earlier quoted context omitted.

> This is one half of the innovation, dependent-types lite. But that's not dependent types. Dependent types are types that depend on values. If all the arguments to a function are either types or values, then you don't have dependent types: you have kind polymorphism, as implemented for example in GHC extensions [1]. > The second half is how every other major feature is expressed _directly_ via comptime/partial evalu…

> Dependent types are types that depend on values. Like this? fn f(comptime x: bool) if (x) u32 else bool { return if (x) 0 else false; }

No, dependent types depend on runtime values.

Re: Things Zig comptime won't do

#212

Post by edflsafoiewq »

pron wrote: post #203
pcwalton wrote: post #202

Earlier quoted context omitted.

I think another way to put it is that the fact that Zig reuses the keyword "comptime" to denote type-level parameters and to denote compile-time evaluation doesn't mean that there's only one feature. There are still two features (templates and CTFE), just two features that happen to use the same keyword.

Maybe you can insist that these are two features (although I disagree), but calling one of them templates really misses the mark. That's because, at least in C++, templates have their own template-level language (of "metafunctions"), whereas that's not the case in Zig. E.g. that C++'s `std::enable_if` is just the regular `if` in Zig makes all the difference (and also shows why there may not really be two features her…

std::enable_if exists to disable certain overloads during overload resolution. Zig has no overloading, so it has no equivalent.

Re: Things Zig comptime won't do

#213

Post by matklad »

pron wrote: post #207
pcwalton wrote: post #197

Earlier quoted context omitted.

But Zig's comptime only approximates the features you mentioned; it doesn't fully implement them. Which is what the original article is saying. To use your analogy, using a touchscreen to eliminate a keyboard isn't very impressive if your touchscreen keyboard is missing keys. If you say that incomplete implementations count, then I could argue that the C preprocessor subsumes generics/templates, interfaces/typeclasse…

> But Zig's comptime only approximates the features you mentioned; it doesn't fully implement them That's like saying that a touchscreen device without a keyboard only approximates a keyboard but doesn't fully implement one. The important thing is that the feature performs the duty of those other features. > If you say that incomplete implementations count, then I could argue that the C preprocessor subsumes generics…

>I'm not saying it may not have other problems, but that is very novel.

Just to explicitly acknowledge this, it inherits the C++ problem that you don't get type errors inside a function until you call the function and, when that happens, its not always immediately obvious whether the problem is in the caller or in the callee.

Re: Things Zig comptime won't do

#214

Post by matklad »

edflsafoiewq wrote: post #211
matklad wrote: post #206

Earlier quoted context omitted.

> Dependent types are types that depend on values. Like this? fn f(comptime x: bool) if (x) u32 else bool { return if (x) 0 else false; }

No, dependent types depend on runtime values.

Yeah, that one Zig can not do, hence "-lite".

Re: Things Zig comptime won't do

#215

Post by bsder »

SleepyMyroslav wrote: post #146
bsder wrote: post #55

Earlier quoted context omitted.

> The zig community bewilders me at times with their love for lashing themselves. The sort of discussions which new sort of self-harm they'd love to enforce on everybody is borderline disturbing. Personally, I find the idea that a compiler might be able to reach outside itself completely terrifying (Access the network or a database? Are you nuts?). That should be 100% the job of a build system. Now, you can certainly…

>Personally, I find the idea that a compiler might be able to reach outside itself completely terrifying (Access the network or a database? Are you nuts?). In gamedev code is small part of the end product. "Data-driven" is the term if you want to look it up. Doing an optimization pass that will partially evaluate data+code together as part of the build is normal. Code has like 'development version' that supports data…

Is the PGO data not a static file which is then fed into the compiler? That still gives you a deterministic compiler, no?

Re: Things Zig comptime won't do

#216

Post by matklad »

edflsafoiewq wrote: post #212
pron wrote: post #203

Earlier quoted context omitted.

Maybe you can insist that these are two features (although I disagree), but calling one of them templates really misses the mark. That's because, at least in C++, templates have their own template-level language (of "metafunctions"), whereas that's not the case in Zig. E.g. that C++'s `std::enable_if` is just the regular `if` in Zig makes all the difference (and also shows why there may not really be two features her…

std::enable_if exists to disable certain overloads during overload resolution. Zig has no overloading, so it has no equivalent.

I'd flip it over and say that C++ has overloading&SFINAE to enable polymorphism which it otherwise can't express.

Re: Things Zig comptime won't do

#217

Post by pcwalton »

matklad wrote: post #206
pcwalton wrote: post #201

Earlier quoted context omitted.

> This is one half of the innovation, dependent-types lite. But that's not dependent types. Dependent types are types that depend on values. If all the arguments to a function are either types or values, then you don't have dependent types: you have kind polymorphism, as implemented for example in GHC extensions [1]. > The second half is how every other major feature is expressed _directly_ via comptime/partial evalu…

> Dependent types are types that depend on values. Like this? fn f(comptime x: bool) if (x) u32 else bool { return if (x) 0 else false; }

That's still just a function of type ∀K∀L.K → L with a bound on K. From a type theory perspective, a comptime argument, when the function is used in such a way as to return a type, is not a value, even though it looks like one. Rather, true or false in this context is a type. (Yes, really. This is a good example of why Zig reusing the keyword "comptime" obscures the semantics.) If comptime true or comptime false were actually values, then you could put runtime values in there too.

Re: Things Zig comptime won't do

#218

Post by pcwalton »

matklad wrote: post #214
edflsafoiewq wrote: post #211

Earlier quoted context omitted.

No, dependent types depend on runtime values.

Yeah, that one Zig can not do, hence "-lite".

The point is that comptime isn't dependent types at all. If your types can't depend on runtime values, they aren't dependent types. It's something more like kind polymorphism in GHC (except more dynamically typed), something which GHC explicitly calls out as not dependent types. (Also it's 12 years old [1]).

[1]: https://www.seas.upenn.edu/~sweirich/papers/fckinds.pdf

Re: Things Zig comptime won't do

#219

Post by minetest2048 »

bunderbunder wrote: post #171

Zig has a completely different feature, partial evaluation/specialization, which, none the less, is enough to cover most of use-cases for dynamic code generation. These kinds of insights are what I love about Zig. Andrew Kelley just might be the patron saint of the KISS principle. A long time ago I had an enlightenment experience where I was doing something clever with macros in F#, and it wasn't until I had more-or-…

Fortunately its not just you, in Julia community there's a thread that discusses why you shouldn't use metaprogramming as a first solution as multiple dispatch and higher order functions are cleaner and faster: https://discourse.julialang.org/t/how-to-warn-new-users-away...

Re: Things Zig comptime won't do

#220

Post by edflsafoiewq »

matklad wrote: post #216
edflsafoiewq wrote: post #212

Earlier quoted context omitted.

std::enable_if exists to disable certain overloads during overload resolution. Zig has no overloading, so it has no equivalent.

I'd flip it over and say that C++ has overloading&SFINAE to enable polymorphism which it otherwise can't express.

Such as? The basic property of overloading is it's open. Any closed set of overloads can be converted to a single function which does the same dispatch logic with ifs and type traits (it may not be very readable).
Post reply on HN