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

231–240 of 252 posts

Re: Things Zig comptime won't do

#231

Post by foobazgt »

pron wrote: post #157
foobazgt wrote: post #114

Earlier quoted context omitted.

Just because something mucks with a program's AST doesn't mean that it's introducing a new "language". You wouldn't call using reflection, "creating a new language", either, and many of these libraries can be implemented either way. (Usually a choice between adding an additional build step, runtime overhead, and ease of implementation). It just really depends upon the details of the transform. The integrity by defaul…

> Just because something mucks with a program's AST doesn't mean that it's introducing a new "language". That depends on the language specification. The Java spec dictates what code a Java compiler must accept and must reject . Any "mucking with AST" that changes that is, by definition, not Java. For example, many Lombok programs are clearly not written in Java because the Java spec dictates that a Java compiler (wit…

Thanks for clarifying your role in the JEP.

I feel like we're talking right past one another. The ultimate reality is that annotation processors are pretty terrible for implementing functionality that a lot of Java developers depend upon. You could say annotation processors "weren't designed for that", but then you're just agreeing with me. This is sad, because arguably something quite similar to annotation processors could make the jobs of all of these developers a lot easier, instead of having them falling back to other mechanisms.

If your concern is integrity by default, why not just add yet another flag for can-muck-with-the-ast-annotation-processors? Or we can continue with the status quo.

Re: Things Zig comptime won't do

#232

Post by WalterBright »

pron wrote: post #227
pcwalton wrote: post #225

Earlier quoted context omitted.

> The important thing is that the feature performs the duty of those other features. Zig's comptime doesn't do everything that Rust (or Java, or C#, or Swift, etc.) generics do, and I know you know this given your background in type theory. Zig doesn't allow for the inference and type-directed method resolution that Rust or the above languages do, because the "generics" that you create using Zig comptime aren't typec…

> Zig doesn't allow for the inference and type-directed method resolution that Rust or the above languages do Well, but Zig also doesn't allow for overloads and always opts for explicitness regardless of comptime, so I would say that's consonant with the rest of the design. > Now I imagine you think that this feature doesn't matter, or at least doesn't matter enough to be worth the complexity it adds to the compiler.…

> the notion of a comptime variable (for which I couldn't find an analogue in D)

A comptime variable in D would look like:

    enum v = foo(3);
Since an enum initialization is a ConstExpression, it's initialization must be evaluated at compile time.

A comptime function parameter in D looks like:

    int mars(int x)(int y) { ... }
where the first parameter list consists of compile time parameters, and the second the runtime parameters.

D does not have a switch-over-types statement, but the equivalent can be done with a sequence of static-if statements:

    static if (is(T == int)) { ... }
    else static if (is(T == float)) { ... }
Static If is always evaluated at compile time. The IsExpression does pattern matching on types.

Re: Things Zig comptime won't do

#233

Post by pron »

foobazgt wrote: post #231
pron wrote: post #157

Earlier quoted context omitted.

> Just because something mucks with a program's AST doesn't mean that it's introducing a new "language". That depends on the language specification. The Java spec dictates what code a Java compiler must accept and must reject . Any "mucking with AST" that changes that is, by definition, not Java. For example, many Lombok programs are clearly not written in Java because the Java spec dictates that a Java compiler (wit…

Thanks for clarifying your role in the JEP. I feel like we're talking right past one another. The ultimate reality is that annotation processors are pretty terrible for implementing functionality that a lot of Java developers depend upon. You could say annotation processors "weren't designed for that", but then you're just agreeing with me. This is sad, because arguably something quite similar to annotation processor…

> If your concern is integrity by default, why not just add yet another flag for can-muck-with-the-ast-annotation-processors?

There is such a flag (or, rather, a set of flags), and that's exactly what the Lombok compiler uses to change javac to compile Lombok sources rather than Java sources.

However, we think there are much better solutions to the problem those languages try to solve than allowing AST manipulation.

Re: Things Zig comptime won't do

#234

Post by pron »

WalterBright wrote: post #232
pron wrote: post #227

Earlier quoted context omitted.

> Zig doesn't allow for the inference and type-directed method resolution that Rust or the above languages do Well, but Zig also doesn't allow for overloads and always opts for explicitness regardless of comptime, so I would say that's consonant with the rest of the design. > Now I imagine you think that this feature doesn't matter, or at least doesn't matter enough to be worth the complexity it adds to the compiler.…

> the notion of a comptime variable (for which I couldn't find an analogue in D) A comptime variable in D would look like: enum v = foo(3); Since an enum initialization is a ConstExpression , it's initialization must be evaluated at compile time. A comptime function parameter in D looks like: int mars(int x)(int y) { ... } where the first parameter list consists of compile time parameters, and the second the runtime…

A comptime variable in Zig isn't a constant whose value is computed at compile time (that would just be a Zig constant) but rather variable that's potentially mutable by comptime: https://ziglang.org/documentation/master/#Compile-Time-Varia...

This is one of the things that allow the "comptime language" to just be Zig, as in this example: https://ziglang.org/documentation/master/#Case-Study-print-i...

Re: Things Zig comptime won't do

#235

Post by keybored »

pron wrote: post #184
keybored wrote: post #182

Earlier quoted context omitted.

> What you're saying isn't very meaningful. Even generics may impose restrictions on their type parameters (e.g. typeclasses in Zig or type bounds in Java) and don't necessarily work for all types. In both cases you know at compile-time whether your types fit the bounds or not. Java type-bounds is what I mean with declarative. The library author wrote them, I know them, I have to follow them. It’s all spelled out. Ac…

> According to the link that’s not the case with the Zig comptime machinery. It’s effectively duck-typed from the point of view of the client (declaration). It is "duck-typed", but it is checked at compile time . Unlike ducktyping in JS, you know whether or not your type is a valid argument just as you would for Java type bounds -- the compiler lets you know. Everything is also all spelled out, just in a different wa…

> It is "duck-typed", but it is checked at compile time. Unlike ducktyping in JS, you know whether or not your type is a valid argument just as you would for Java type bounds -- the compiler lets you know. Everything is also all spelled out, just in a different way.

At this point I will have to defer to Zig users.

But the wider point stands whether I am correct about Zig usability or not (mostly leaning on the aforelinked URLs). Plenty of things can be compile-time and yet have widely different usability. Something that relies on unconstrained build-time code generation can be much harder to use than macros, which in turn can be harder to use than something like “constant expressions”, and so on.

Re: Things Zig comptime won't do

#236

Post by pcwalton »

pron wrote: post #234
WalterBright wrote: post #232

Earlier quoted context omitted.

> the notion of a comptime variable (for which I couldn't find an analogue in D) A comptime variable in D would look like: enum v = foo(3); Since an enum initialization is a ConstExpression , it's initialization must be evaluated at compile time. A comptime function parameter in D looks like: int mars(int x)(int y) { ... } where the first parameter list consists of compile time parameters, and the second the runtime…

A comptime variable in Zig isn't a constant whose value is computed at compile time (that would just be a Zig constant) but rather variable that's potentially mutable by comptime: https://ziglang.org/documentation/master/#Compile-Time-Varia... This is one of the things that allow the "comptime language" to just be Zig, as in this example: https://ziglang.org/documentation/master/#Case-Study-print-i...

You can mutate variables at compile time in D. See the compile time Newton's method example: https://tour.dlang.org/tour/en/gems/compile-time-function-ev...

Re: Things Zig comptime won't do

#237

Post by pron »

pcwalton wrote: post #236
pron wrote: post #234

Earlier quoted context omitted.

A comptime variable in Zig isn't a constant whose value is computed at compile time (that would just be a Zig constant) but rather variable that's potentially mutable by comptime: https://ziglang.org/documentation/master/#Compile-Time-Varia... This is one of the things that allow the "comptime language" to just be Zig, as in this example: https://ziglang.org/documentation/master/#Case-Study-print-i...

You can mutate variables at compile time in D. See the compile time Newton's method example: https://tour.dlang.org/tour/en/gems/compile-time-function-ev...

I don't think that's the same thing (rather, it's more like ordinary Zig variables in code that's evaluated at compile-time), as there's no arbitrary mixing of compile-time and runtime computation. Again, compare with https://ziglang.org/documentation/master/#Case-Study-print-i...

Anyway, I found this article that concludes that D's compile time evaluation is equivalent in power to Zig's, although it also doesn't cover how comptime variables can be used in Zig: https://renato.athaydes.com/posts/comptime-programming

However, as I've said many times, knowing about the theoretical power of partial evaluation, what excites me in Zig isn't what comptime can do (although I am impressed with the syntactic elegance of the mechanism) but how it is used to avoid adding other features.

A phone with a touchscreen is evolutionary; a phone without a keypad is revolutionary. The revolution is in the unique experience of using "just comptime" for many things.

It is, of course, a tradeoff, and whether or not that tradeoff is "good" remains to be seen, but I think this design is one of the most novel designs in programming languages in many, many years.

Re: Things Zig comptime won't do

#238

Post by foobazgt »

pron wrote: post #233
foobazgt wrote: post #231

Earlier quoted context omitted.

Thanks for clarifying your role in the JEP. I feel like we're talking right past one another. The ultimate reality is that annotation processors are pretty terrible for implementing functionality that a lot of Java developers depend upon. You could say annotation processors "weren't designed for that", but then you're just agreeing with me. This is sad, because arguably something quite similar to annotation processor…

> If your concern is integrity by default, why not just add yet another flag for can-muck-with-the-ast-annotation-processors? There is such a flag (or, rather, a set of flags), and that's exactly what the Lombok compiler uses to change javac to compile Lombok sources rather than Java sources. However, we think there are much better solutions to the problem those languages try to solve than allowing AST manipulation.

You've referenced Lombok a lot here, and some Google searches later, I can see that you're in conversations all over the internet re: Lombok (and similar projects like Manifold). Their purpose is to extend the Java language. The class of code I'm referring to is more like those you already mention in your JEP: logging, tracing, profiling, serialization, authn/authz, mocking, ffi, and so on. I would describe all of those as fitting under the umbrella of "cross-cutting" and needing a "meta-programming" facility.

> However, we think there are much better solutions

I'd like to hear more. Can I discuss this further with you in a more appropriate venue than this forever thread?

Re: Things Zig comptime won't do

#239

Post by pron »

foobazgt wrote: post #238
pron wrote: post #233

Earlier quoted context omitted.

> If your concern is integrity by default, why not just add yet another flag for can-muck-with-the-ast-annotation-processors? There is such a flag (or, rather, a set of flags), and that's exactly what the Lombok compiler uses to change javac to compile Lombok sources rather than Java sources. However, we think there are much better solutions to the problem those languages try to solve than allowing AST manipulation.

You've referenced Lombok a lot here, and some Google searches later, I can see that you're in conversations all over the internet re: Lombok (and similar projects like Manifold). Their purpose is to extend the Java language. The class of code I'm referring to is more like those you already mention in your JEP: logging, tracing, profiling, serialization, authn/authz, mocking, ffi, and so on. I would describe all of th…

> The class of code I'm referring to is more like those you already mention in your JEP: logging, tracing, profiling, serialization, authn/authz, mocking, ffi, and so on. I would describe all of those as fitting under the umbrella of "cross-cutting" and needing a "meta-programming" facility.

Those are traditionally offered in Java in the form of bytecode transformation rather than AST transformations, as the notion of "compile time" in Java is not as clear as it is in, say, Zig; Project Leyden will make it even more vague, as it will allow caching JIT output from one run to the next.

> Can I discuss this further with you in a more appropriate venue than this forever thread?

Sure, you can email me at the email address I use on the JDK mailing lists (e.g. loom-dev).

Re: Things Zig comptime won't do

#240

Post by foobazgt »

pron wrote: post #239
foobazgt wrote: post #238

Earlier quoted context omitted.

You've referenced Lombok a lot here, and some Google searches later, I can see that you're in conversations all over the internet re: Lombok (and similar projects like Manifold). Their purpose is to extend the Java language. The class of code I'm referring to is more like those you already mention in your JEP: logging, tracing, profiling, serialization, authn/authz, mocking, ffi, and so on. I would describe all of th…

> The class of code I'm referring to is more like those you already mention in your JEP: logging, tracing, profiling, serialization, authn/authz, mocking, ffi, and so on. I would describe all of those as fitting under the umbrella of "cross-cutting" and needing a "meta-programming" facility. Those are traditionally offered in Java in the form of bytecode transformation rather than AST transformations, as the notion o…

> Those are traditionally offered in Java in the form of bytecode transformation

And we've come full circle. I think they're traditionally written as bytecode transformations, because the entire pipeline for both writing and using many kinds of program transformations in bytecode is far simpler, more accessible, and more performant than implementing and executing a source-to-source compiler that feeds into another java compiler.

That said, there are also times you wish to perform transforms on programs for which you don't have access to source, in which case your hand is forced. Ideally, you would be able to write many classes of transforms agnostic to that context.

> Sure

Thanks!

Post reply on HN