3 ms·

Like the other comment mentioned, this is staging. > And compared to Lisps like Scheme and Racket which support hygenic macros, well, Zig doesn’t require every

Like the other comment mentioned, this is staging. > And compared to Lisps like Scheme and Racket which support hygenic macros, well, Zig doesn’t require everything to be a list. This comment is a bit ignorant. Racket has the most advanced staging system of any language that I'm aware of. You can build languages in Racket with conventional yet extensible syntax: https://docs.racket-lang.org/rhombus/index.html https://docs.racket-lang.org/rhombus/index.html Zig's metaprogramming facilities are very simple in comparison. I think staging could be extremely useful in many application, and I wish it was better supported in mainstream langauges.

eru 2y ago
I guess accusing Lisps of only supporting lists as their data structures has the pedigree of a long established tradition by now? (Though I wish they would at least accuse them of everything having to be cons-pairs.)
- Y_Y 2y ago
  My programs are single atoms
  - eru 2y ago
    I thought the whole point of Lisp was that it allows you to compose bigger programs out of smaller pieces?
    - acka 2y ago
      Please don't distract Y_Y, they may be well on their way to Lisp NILvana: realizing that everything else is impermanent and unsatisfactory. NIL is ultimate bliss.
      - Y_Y 2y ago
        "Perfection is achieved ... when there is nothing [nil] left ..." ― Antoine de Saint-Exupéry
samatman 2y ago
> Zig's metaprogramming facilities are very simple in comparison. They work differently, is the main thing. Racket's #lang extensions are very sophisticated indeed, but/and they do what Lisp-style compile-time evaluation has always done: they build up lists which represent the program, what we'd call an AST in most other languages. Yes, I'm well aware that Racket has more data structures than lists! But that is the output of front ends like Rhombus. Some of those lists represent a program which creates a hash map and so on. That's fine. Zig comptime is part of the compiling process. Sometimes this mutates the AST or IR, often it does not, instead producing object code or .rodata which is embedded into the final binary. The current implementation is a bit ad-hoc, with some arbitrary limitations (no allocation being the big one), but it's a solid design. Already quite useful, even eloquent, and I'm optimistic that the final form will be a real thing of beauty. But it isn't accurate to say that it's 'very simple' in comparison to Racket. They spend their complexity budget in different places.
- noelwelsh 2y ago
  I'm a bit confused by what you're saying. Here are a few points: 1. If you are claiming that "compile-time evaluation" (macros) in Racket works with lists (i.e. the input to a macro is a list, and the output from a macro is a list), that is false. It works with syntax objects: https://docs.racket-lang.org/guide/stx-obj.html https://docs.racket-lang.org/guide/stx-obj.html 2. A macro can do anything. It usually emits syntax, but because it's just code it can print output, play a jaunty tune, or implement type checking. It seems to me that Racket's macros are strictly a super-set of Zig's comptime. Like comptime a macro can do arbitrary computation. However AFAIK there only two stages in Zig (compile-time and run-time) while Racket has an arbitrary number of stages, and macros can, of course, implement new syntactic forms.
  - samatman 2y ago
    > If you are claiming that "compile-time evaluation" (macros) in Racket works with lists (i.e. the input to a macro is a list, and the output from a macro is a list), that is false. It works with syntax objects This is a distinction without a difference. From your quote: > A syntax object contains symbols, lists, and constant values (such as numbers) that essentially correspond to the quoted form of the expression. If it's important to you that it's actually atoms and lists, well, some of us generalize better than others. But calling it false? Lame. As is your feigned confusion. > A macro can do anything Syntax and side effects. Take your pick. > It seems to me that Racket's macros are strictly a super-set of Zig's comptime. The difference here is that you have experience with one of these systems. I have experience with both. I doubt further interactions would be informative for either of us.

eru 2y ago

I guess accusing Lisps of only supporting lists as their data structures has the pedigree of a long established tradition by now? (Though I wish they would at least accuse them of everything having to be cons-pairs.)

Y_Y 2y ago
My programs are single atoms
- eru 2y ago
  I thought the whole point of Lisp was that it allows you to compose bigger programs out of smaller pieces?
  - acka 2y ago
    Please don't distract Y_Y, they may be well on their way to Lisp NILvana: realizing that everything else is impermanent and unsatisfactory. NIL is ultimate bliss.
    - Y_Y 2y ago
      "Perfection is achieved ... when there is nothing [nil] left ..." ― Antoine de Saint-Exupéry

samatman 2y ago

> Zig's metaprogramming facilities are very simple in comparison. They work differently, is the main thing. Racket's #lang extensions are very sophisticated indeed, but/and they do what Lisp-style compile-time evaluation has always done: they build up lists which represent the program, what we'd call an AST in most other languages. Yes, I'm well aware that Racket has more data structures than lists! But that is the output of front ends like Rhombus. Some of those lists represent a program which creates a hash map and so on. That's fine. Zig comptime is part of the compiling process. Sometimes this mutates the AST or IR, often it does not, instead producing object code or .rodata which is embedded into the final binary. The current implementation is a bit ad-hoc, with some arbitrary limitations (no allocation being the big one), but it's a solid design. Already quite useful, even eloquent, and I'm optimistic that the final form will be a real thing of beauty. But it isn't accurate to say that it's 'very simple' in comparison to Racket. They spend their complexity budget in different places.

noelwelsh 2y ago
I'm a bit confused by what you're saying. Here are a few points: 1. If you are claiming that "compile-time evaluation" (macros) in Racket works with lists (i.e. the input to a macro is a list, and the output from a macro is a list), that is false. It works with syntax objects: https://docs.racket-lang.org/guide/stx-obj.html https://docs.racket-lang.org/guide/stx-obj.html 2. A macro can do anything. It usually emits syntax, but because it's just code it can print output, play a jaunty tune, or implement type checking. It seems to me that Racket's macros are strictly a super-set of Zig's comptime. Like comptime a macro can do arbitrary computation. However AFAIK there only two stages in Zig (compile-time and run-time) while Racket has an arbitrary number of stages, and macros can, of course, implement new syntactic forms.
- samatman 2y ago
  > If you are claiming that "compile-time evaluation" (macros) in Racket works with lists (i.e. the input to a macro is a list, and the output from a macro is a list), that is false. It works with syntax objects This is a distinction without a difference. From your quote: > A syntax object contains symbols, lists, and constant values (such as numbers) that essentially correspond to the quoted form of the expression. If it's important to you that it's actually atoms and lists, well, some of us generalize better than others. But calling it false? Lame. As is your feigned confusion. > A macro can do anything Syntax and side effects. Take your pick. > It seems to me that Racket's macros are strictly a super-set of Zig's comptime. The difference here is that you have experience with one of these systems. I have experience with both. I doubt further interactions would be informative for either of us.