←back to thread

Things Zig comptime won't do

(matklad.github.io)
466 points JadedBlueEyes | 10 comments | | HN request time: 1.853s | source | bottom
Show context
pron ◴[] No.43745438[source]
Yes!

To me, the uniqueness of Zig's comptime is a combination of two things:

1. comtpime replaces many other features that would be specialised in other languages with or without rich compile-time (or runtime) metaprogramming, and

2. comptime is referentially transparent [1], that makes it strictly "weaker" than AST macros, but simpler to understand; what's surprising is just how capable you can be with a comptime mechanism with access to introspection yet without the referentially opaque power of macros.

These two give Zig a unique combination of simplicity and power. We're used to seeing things like that in Scheme and other Lisps, but the approach in Zig is very different. The outcome isn't as general as in Lisp, but it's powerful enough while keeping code easier to understand.

You can like it or not, but it is very interesting and very novel (the novelty isn't in the feature itself, but in the place it has in the language). Languages with a novel design and approach that you can learn in a couple of days are quite rare.

[1]: In short, this means that you get no access to names or expressions, only the values they yield.

replies(7): >>43745704 #>>43745928 #>>43746682 #>>43747113 #>>43747250 #>>43749014 #>>43749546 #
User23 ◴[] No.43745704[source]
Has anyone grafted Zig style macros into Common Lisp?
replies(4): >>43745832 #>>43745860 #>>43746089 #>>43753782 #
1. toxik ◴[] No.43745832[source]
Isn’t this kind of thing sort of the default thing in Lisp? Code is data so you can transform it.
replies(2): >>43746555 #>>43747714 #
2. fn-mote ◴[] No.43746555[source]
There are no limitations on the transformations in lisp. That can make macros very hard to understand. And hard for later program transformers to deal with.

The innovation in Zig is the restrictions that limit the power of macros.

3. TinkersW ◴[] No.43747714[source]
Lisp is so powerful, but without static types you can't even do basic stuff like overloading, and have to invent a way to even check the type(for custom types) so you can branch on type.
replies(3): >>43747885 #>>43748318 #>>43749199 #
4. dokyun ◴[] No.43747885[source]
> Lisp is so powerful, but <tired old shit from someone who's never used Lisp>.

You use defmethod for overloading. Types check themselves.

replies(1): >>43751628 #
5. wild_egg ◴[] No.43748318[source]
> but without static types

So add static types.

https://github.com/coalton-lang/coalton

6. pjmlp ◴[] No.43749199[source]
No need for overloading when you have CLOS and multi-method dispatch.
7. User23 ◴[] No.43751628{3}[source]
And a modern compiler will jmp past the type checks if the inferencer OKs it!
replies(1): >>43799011 #
8. aidenn0 ◴[] No.43799011{4}[source]
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.

replies(1): >>43878511 #
9. User23 ◴[] No.43878511{5}[source]
Very interesting comment!

To clarify, as you know CLOS isn’t the CL type system. I was particularly thinking about things like fixnum arithmetic.

The CMUCL and SBCL manual sections on code generation discuss this and it can be verified with DISASSEMBLE.

replies(1): >>43991250 #
10. aidenn0 ◴[] No.43991250{6}[source]
Missed your reply when it happened. Note that you cannot specialize a method on "fixnum" since it's not a class (though you can on "number" or "integer" since they are classes).