5 ms·

comptime does not replace macros though...there is no way to manipulate AST in zig, nor will there ever be, according to the author.

by gw 7y ago

pron 7y ago
Well, it is intentionally weaker than macros (and I agree with Zig's designer that that's a very good thing, though it is a matter of taste), but it does replace many of the cases where in Rust you'd have to use macros (or the preprocessor in C/C++). So it replaces macros everywhere where it deems their usage reasonable.
- gw 7y ago
  It is a legit design choice, but it does detract from your comment about language complexity. Not having AST macros inherently adds complexity to a language by requiring features to be built into the compiler rather than be implemented as libraries.
  - pron 7y ago
    Those are different kinds of complexity. You're talking about the effort required by the implementor of the compiler. I'm talking about the effort required by the programmer using the language.
    - gw 7y ago
      Then you aren't talking about complexity (an objective quality), you are talking about difficulty to read (a subjective quality relative to the reader). There is no doubt that macros can make a given piece of code harder to read, if the reader is unfamiliar with the macro being used. Complexity describes how intertwined different pieces of something are internally, which has nothing to do with a given vantage point.
      - pron 7y ago
        No, that's just how Rich Hickey describes complexity; it's hardly a universal definition. For example, in computer science, the complexity of a task is often a measure of the effort, in time or memory, required to perform it.
        gw 7y ago
        English is certainly not free of ambiguity, but in the past i've seen you heavily emphasize precision in word choice, so it's surprising to see you de-emphasize it here. Nobody is a final arbiter of definitions, but the distinction i'm making is not a trivial one, and Hickey isn't the only one to have made it. Even thinking about it colloquially, how often do you follow the word "complex" with an infinitive verb describing an action? A rube goldberg machine is complex...and hard to build!
        pron 7y ago
        I'm not deemphasizing it, I'm just saying that we're talking about different meanings of "complexity" here and there is no well-accepted definition. My "complexity" refers to the effort required by the programmer when understanding programs written in the language.
        gw 7y ago
        Fair enough, ron. I won't belabor it further. I'll just leave this: Long ago, after coming across a very useful distinction between the words "practical" and "pragmatic," i intentionally changed my usage of those words as a result. Not because a charismatic person told me to, but because it was useful. If a distinction is useful to make, start making it, my man!
AnIdiotOnTheNet 7y ago
Which is the right call really. It is valuable to have the code you're looking at actually be what it appears to be.
- mratsim 7y ago
  I don't agree. For many domains, being able to implement a domain-specific language with a set of expressive rules for the domain is an incredible productivity boost and also prevents many mistakes because you cannot represent them. Not being able to manipulate the AST means that you are restricted on the embedded DSLs that you can provide. And embedded DSLs encompasses code generation for: - state machines - parsing grammars (PEGs for example) - shader languages - numerical computing (i.e. having more math like syntax to manipulate indices) - deep learning (neural network DSL) - HTML templates / generators - monad composition There is a reason most people are not building in Assembly anymore, there is a right-level of abstraction for every domain. A language that provides building block for domain expert to build up to the right level of abstraction is very valuable.
  - deleted 7y ago
    [deleted]
  - pron 7y ago
    The question is, as always, at what cost? Low-level languages (aka "systems programming" languages) already suffer from various constraints that increase their accidental complexity. Is it really necessary to complicate those particular languages further to support embedded DSLs? I don't think there's a universal right or wrong answer here, but there is certainly a big question.
    - gw 7y ago
      Ironically, the lack of macros leads to an explosion of ad-hoc, extra-language DSLs. Look at rules engines, for example. In Drools (java), you have to write rules with a special language, DRL. Meanwhile in Clara (clojure) you write your rules in clojure. Macros simplify languages, they don't complicate them.
curtisf 7y ago
You can't manipulate ASTs (ie, Zig code), but nothing stops you from parsing string literals however you want. For example, I wrote a PEG-like parser combinator library in Zig. Using it currently [looks like this](https://github.com/CurtisFenner/zsmol/blob/87de4c77dd8543011e67ffb603923ecdf48e5565/src/grammar.zig#L706-L724 https://github.com/CurtisFenner/zsmol/blob/87de4c77dd8543011...). However, as a library, I ^could provide a function that looks like pub const UnionDefinition = comb.fromLiteral( \\ _: KeyUnion \\ union_name: TypeIden \\ generics: Generics? \\ implements: Implements? \\ _: PuncCurlyOpen \\ fields: Field* \\ members: FunctionDef* \\ _: PuncCurlyClose ); etc. But, I find reading the code as it is good enough for now that I didn't want to spend time implementing such a library. [^]: Being able to create brand new types at `comptime` isn't [yet implemented](https://github.com/ziglang/zig/issues/383 https://github.com/ziglang/zig/issues/383), so this can't quite be done yet, though you could fake it with `get`/`set` methods instead of real fields

comptime does not replace macros though...there is no way to manipulate AST in zig, nor will there ever be, according to the author.

by gw 7y ago

comptime does not replace macros though...there is no way to manipulate AST in zig, nor will there ever be, according to the author.

pron 7y ago

Well, it is intentionally weaker than macros (and I agree with Zig's designer that that's a very good thing, though it is a matter of taste), but it does replace many of the cases where in Rust you'd have to use macros (or the preprocessor in C/C++). So it replaces macros everywhere where it deems their usage reasonable.

gw 7y ago
It is a legit design choice, but it does detract from your comment about language complexity. Not having AST macros inherently adds complexity to a language by requiring features to be built into the compiler rather than be implemented as libraries.
- pron 7y ago
  Those are different kinds of complexity. You're talking about the effort required by the implementor of the compiler. I'm talking about the effort required by the programmer using the language.
  - gw 7y ago
    Then you aren't talking about complexity (an objective quality), you are talking about difficulty to read (a subjective quality relative to the reader). There is no doubt that macros can make a given piece of code harder to read, if the reader is unfamiliar with the macro being used. Complexity describes how intertwined different pieces of something are internally, which has nothing to do with a given vantage point.
    - pron 7y ago
      No, that's just how Rich Hickey describes complexity; it's hardly a universal definition. For example, in computer science, the complexity of a task is often a measure of the effort, in time or memory, required to perform it.
      - gw 7y ago
        English is certainly not free of ambiguity, but in the past i've seen you heavily emphasize precision in word choice, so it's surprising to see you de-emphasize it here. Nobody is a final arbiter of definitions, but the distinction i'm making is not a trivial one, and Hickey isn't the only one to have made it. Even thinking about it colloquially, how often do you follow the word "complex" with an infinitive verb describing an action? A rube goldberg machine is complex...and hard to build!
        pron 7y ago
        I'm not deemphasizing it, I'm just saying that we're talking about different meanings of "complexity" here and there is no well-accepted definition. My "complexity" refers to the effort required by the programmer when understanding programs written in the language.
        gw 7y ago
        Fair enough, ron. I won't belabor it further. I'll just leave this: Long ago, after coming across a very useful distinction between the words "practical" and "pragmatic," i intentionally changed my usage of those words as a result. Not because a charismatic person told me to, but because it was useful. If a distinction is useful to make, start making it, my man!

AnIdiotOnTheNet 7y ago

Which is the right call really. It is valuable to have the code you're looking at actually be what it appears to be.

mratsim 7y ago
I don't agree. For many domains, being able to implement a domain-specific language with a set of expressive rules for the domain is an incredible productivity boost and also prevents many mistakes because you cannot represent them. Not being able to manipulate the AST means that you are restricted on the embedded DSLs that you can provide. And embedded DSLs encompasses code generation for: - state machines - parsing grammars (PEGs for example) - shader languages - numerical computing (i.e. having more math like syntax to manipulate indices) - deep learning (neural network DSL) - HTML templates / generators - monad composition There is a reason most people are not building in Assembly anymore, there is a right-level of abstraction for every domain. A language that provides building block for domain expert to build up to the right level of abstraction is very valuable.
- deleted 7y ago
  [deleted]
- pron 7y ago
  The question is, as always, at what cost? Low-level languages (aka "systems programming" languages) already suffer from various constraints that increase their accidental complexity. Is it really necessary to complicate those particular languages further to support embedded DSLs? I don't think there's a universal right or wrong answer here, but there is certainly a big question.
  - gw 7y ago
    Ironically, the lack of macros leads to an explosion of ad-hoc, extra-language DSLs. Look at rules engines, for example. In Drools (java), you have to write rules with a special language, DRL. Meanwhile in Clara (clojure) you write your rules in clojure. Macros simplify languages, they don't complicate them.

curtisf 7y ago

You can't manipulate ASTs (ie, Zig code), but nothing stops you from parsing string literals however you want. For example, I wrote a PEG-like parser combinator library in Zig. Using it currently [looks like this](https://github.com/CurtisFenner/zsmol/blob/87de4c77dd8543011e67ffb603923ecdf48e5565/src/grammar.zig#L706-L724 https://github.com/CurtisFenner/zsmol/blob/87de4c77dd8543011...). However, as a library, I ^could provide a function that looks like pub const UnionDefinition = comb.fromLiteral( \\ _: KeyUnion \\ union_name: TypeIden \\ generics: Generics? \\ implements: Implements? \\ _: PuncCurlyOpen \\ fields: Field* \\ members: FunctionDef* \\ _: PuncCurlyClose ); etc. But, I find reading the code as it is good enough for now that I didn't want to spend time implementing such a library. [^]: Being able to create brand new types at `comptime` isn't [yet implemented](https://github.com/ziglang/zig/issues/383 https://github.com/ziglang/zig/issues/383), so this can't quite be done yet, though you could fake it with `get`/`set` methods instead of real fields