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

241–250 of 252 posts

Re: Things Zig comptime won't do

#241

Post by CRConrad »

bsder wrote: post #55
ephaeton wrote: post #30

zig's comptime has some (objectively: debatable? subjectively: definite) shortcomings that the zig community then overcomes with zig build to generate code-as-strings to be lateron @imported and compiled. Practically, "zig build"-time-eval. As such there's another 'comptime' stage with more freedom, unlimited run-time (no @setEvalBranchQuota), can do IO (DB schema, network lookups, etc.) but you lose the freedom to g…

> 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 of needing something called a "build system" completely terrifying.

Re: Things Zig comptime won't do

#242

Post by CRConrad »

forrestthewoods wrote: post #105
int_19h wrote: post #102

Earlier quoted context omitted.

Can you give an example of a use case where you wouldn't want comptime behavior to match runtime, but instead expose host/target differences?

Let’s pretend I was writing some compile-time code that generates code. For example maybe I’m generating serde code. Or maybe I’m generating bindings for C, Python, etc. My generation code is probably going to allocate some memory and have some pointers and do some stuff. Why on earth would I want this compile-time code to run on an emulated version of the target platform? If I’m on a 64-bit platform then pointers ar…

> Why on earth would I want this compile-time code to run on an emulated version of the target platform? If I’m on a 64-bit platform then pointers are 8-bytes why would I pretend they aren’t? Even if the target is 32-bit? Does that make sense?

Nope, sorry, to me it doesn't. If you're cross-compiling for some other platform, then yes, I'd think you want the generated binary to be compatible with the target platform. And in order to verify that that binary code is correct for that target platform, you need to "allocate some memory and have some pointers and do some stuff" as you do on that platform.

So why on Earth would you want stuff -- like pointer sizes and whatnot -- to not be compatible with the target platform, but with whatever you happen to be compiling on? What good is pointer size compatibility with your compiling platform to a user of your end-result binary on the target platform? Looks like the mother of all it-worked-on-my-machine statements: "Whaddaya mean it has memory allocation errors on your machine? I ran it as if for my totally-different machine at compile-time, so of course it works on yours!"

Re: Things Zig comptime won't do

#243

Post by pron »

WalterBright wrote: post #224
msteffen wrote: post #221

Earlier quoted context omitted.

IIUC, it does have code generation—the ability to generate strings at compile-time and feed them back into the compiler. The argument that the author of TFA is making is that Zig’s comptime is a very limited feature (which, they argue, is good. It restricts users from introducing architecture dependencies/cross-compilation bugs, is more amenable to optimization, etc), and yet it allows users to do most of the things…

> Zig’s “No host leakage” (to guarantee cross-compile-ability) looks like the one possibly substantively different thing. That is a good idea, but could be problematic if one relies on size_t, which changes in size from 32 to 64 bit. D's CTFE adds checks for undefined behavior, such as shifting by more bits than are in the type being shifted. These checks are not done at runtime for performance reasons. D's CTFE also…

Because Zig supports cross-compilation, what you care about isn't the host -- the machine that runs the compiler -- but the target, which is not (necessarily) the same as the host. While information about the host isn't made available, information about the compilation target is: https://ziglang.org/documentation/master/#Compile-Variables

Re: Things Zig comptime won't do

#244

Post by xedrac »

rastignack wrote: post #54
nicce wrote: post #51

Earlier quoted context omitted.

> refactor codebase are rust’s main drawbacks Hard disagree about refactoring. Rust is one of the few languages where you can actually do refactoring rather safely without having tons of tests that just exist to catch issues if code changes.

Lifetimes and generic tend to leak so you have to modify your code all around the place when you touch them though.

Explicit lifetimes are not super common, and I haven't had any trouble with them causing refactor headaches. Generics obviously do leak, the same way that C++ templates do.

Re: Things Zig comptime won't do

#245

Post by amszmidt »

Someone wrote: post #183
WalterBright wrote: post #179

Earlier quoted context omitted.

True, but consider that Forth and Lisp started out as interpreted languages, meaning the whole thing can be done at compile time. I haven't seen this feature before in a language that was designed to be compiled to machine code, such as C, Pascal, Fortran, etc. BTW, D's ImportC C compiler does CTFE, too!! CTFE is a natural fit for C, and works like a champ. Standard C should embrace it.

Nitpick: Lisp didn’t start out as an interpreted language. It started as an idea from a theoretical computer scientist, and wasn’t supposed to be implemented. https://en.wikipedia.org/wiki/Lisp_(programming_language)#Hi... : "Steve Russell said, look, why don't I program this eval ... and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ah…

Steve Russell comment is about writing the actual interpreter for Lisp, so the comment is correct on that Lisp started out as an interpreted language, and even mentions that in the comment that you quote.

The interpreter (i.e. Lisp READ-EVAL-PRINT loop) was written in IBM 704 machine code, which just was a reimplementation of the EVAL function as JMC described it in his paper.

The part that "wasn't supposed to be implemented" was about the form of Lisp, M-expressions vs. S-expressions not Lisp it self. Which was supposed to be implemented as a programming system from day one.

Re: Things Zig comptime won't do

#246

Post by aidenn0 »

User23 wrote: post #163
dokyun wrote: post #116

Earlier quoted context omitted.

> Lisp is so powerful, but . You use defmethod for overloading. Types check themselves.

And a modern compiler will jmp past the type checks if the inferencer OKs it!

Which the inferencer probably can't do because of how dynamic standard-class can be. Also, if we want to get pedantic, method-dispatch does not dispatch on types in Common Lisp, but rather via EQL or the class of the argument. Since sub-classes can be made (and methods added or even removed) after a method invocation is compiled, there is no feasible way in a typical lisp implementation[1] to do compile-time dispatch of any type that is a subtype of standard-object.

Now none of this prevents you from extending lisp in such a way that lets you freeze the method dispatch (see e.g. https://github.com/alex-gutev/static-dispatch), but "a modern compiler will jmp past the type checks" is false for all of the CLOS implementations I'm familiar with.

1: SICL is a research implementation that has first-class global environments. If you save the global-environment of a method invocation, you can re-compile the invocation whenever a method is defined (or removed) and get static-dispatch. There's a paper somewhere (probably on metamodular?) that discusses this possibility.

Re: Things Zig comptime won't do

#247

Post by aidenn0 »

Zambyte wrote: post #44
User23 wrote: post #33

Earlier quoted context omitted.

Has anyone grafted Zig style macros into Common Lisp?

There isn't really as clear of a distinction between "runtime" and "compile time" in Lisp. The comptime keyword is essentially just the opposite of quote in Lisp. Instead of using comptime to say what should be evaluated early, you use quote to say what should be evaluated later. Adding comptime to Lisp would be weird (though obviously not impossible, because it's Lisp), because that is essentially the default for ex…

Since we are specifically speaking about Common Lisp, there certainly is; see e.g. https://www.lispworks.com/documentation/HyperSpec/Body/s_eva...

Re: Things Zig comptime won't do

#249

Post by tines »

tines wrote: post #248
bibanez wrote: post #158

Earlier quoted context omitted.

A mobius strip made out of paper has 2 sides, the usual one and the edge.

You can make it out of some other material that you can smooth, i.e. so that it doesn’t have edges.

Come to think of it, doesn't a sphere have only one side?

Re: Things Zig comptime won't do

#250

Post by User23 »

pron wrote: post #173
User23 wrote: post #33

Earlier quoted context omitted.

Has anyone grafted Zig style macros into Common Lisp?

That wouldn't be very meaningful. The semantics of Zig's comptime is more like that of subroutines in a dynamic language - say, JavaScript functions - than that of macros. The point is that it's executed, and yields errors, at a different phase, i.e. compile time.

You can do that, I think, with EVAL-WHEN.
Post reply on HN