Live data from Hacker News

C Macro Reflection in Zig

jstrieb.github.io

71–80 of 139 posts

Re: C Macro Reflection in Zig

#71
post #2

@cImport is on the chopping block though [0]. You will still be able to import c files but it will require a little more work. This is because they want this functionality out of the language so they can remove libclang dependency. [0]: https://github.com/ziglang/zig/issues/20630

It would actually be nice if the translate-c build system step would also allow some restricted symbol transformation (at least stripping the 'namespace prefix' from C library symbols). For instance Odin allows to define a 'link_prefix' for C APIs which is then stripped from the imported symbols: @(default_calling_convention="c", link_prefix="sg_") This causes name transformations like: sg_setup() => setup() sg_shutd…

> common case-conventions

Unfortunately, we must not forget forget ABOMINATIONCase and NAMESPACED_PascalCase (we could also generalize this to any switch from one convention to another after the first word). I've found they usually are, in fact, identifiable and roundtrippable. I've found the following usually works (it fails for multi-word prefixes or non-leading exceptions, and of course single-word identifiers are ambiguous):

  count and strip all leading, then trailing, symbols (in some languages this is not limited to underscore but said languages usually need special handling anyway)
  for every chunk separated by underscore, space, or hyphen (this may be nothing):
    if the chunk either has no uppercase or has no lowercase, simply use it as a word. Otherwise:
    for every sliding-window pair of letters (c, d) in the chunk:
      if c is uppercase:
        if d is lowercase, or d is a digit and there is lowercase elsewhere:
          start a new word before c
Then for the words-to-convention direction:

  space and kebab case don't have any good answer for affixes AFAIK. Otherwise, restore at least the leading underscores (trailing underscores are usually keyword-avoiding)
  for snake and screaming case, be sure to prepend an underscore if the *result* would start with a digit
  for camel variants, prepend an underscore to each *word* that starts with a digit. But if there were originally more than 1 leading underscores, use those instead for the first word.

Re: C Macro Reflection in Zig

#72
post #54

Earlier quoted context omitted.

Not involved with Zig at all, but this comment is a bit concerning : > This is not the first controversial change I have made to the Zig project, and it won't be the last. I have a vision, and I know how to execute it. People are often surprised by what Zig has accomplished, and they wonder why other projects have not done what Zig does. Well, you are seeing the magic right now. I ignore the peanut gallery and do wha…

Wow, that actually makes me want to look into zig a lot more. so many projects, rust included, get bogged down in design by committee and half baked decisions that please no one.

Agreed. Andrew Kelley's ability to have, communicate and maintain a clear and consistent vision is one of the most refreshing things about Zig. I don't actually use it, but this might actually be the main thing attracting me to it.

Plenty has already been said about design-by-committee and relying overmuch on user feedback, but one thing that doesn't get mentioned as often is that this approach tends to transform additive bias[1] from a cognitive bias into an iron law. Once you let that happen, you're on a relatively short and slippery slope to having a kitchen sink language. And one refreshing thing about Zig is that's it's clearly working very hard at not becoming a kitchen sink language. I'm not sure I can say the same about most other newer systems programming languages.

That doesn't mean having a BDFL is all kittens and rainbows, and I'm sure Andrew has made plenty of mistakes. But I've also never seen any indication that he's acted out of anything other than good faith. That last paragraph is possibly the closest I've ever seen to him saying something arrogant, and I see it as the exception that proves the rule. Finding such a tactful way to remind people that this is a BDFL project and he's the BDFL could not have been easy, and I imagine he put a lot of care into crafting that paragraph.

1: https://www.scientificamerican.com/article/our-brain-typical...

Re: C Macro Reflection in Zig

#73
post #32

Earlier quoted context omitted.

As with all VSCode language extensions, they will try to download and manage ZLS for you. That's ok if it's done well, but they probably have some ways to go still. I just prefer using Zig on emacs with the built-in eglot LSP client. You just tell it where you installed ZLS (and it won't do magic to get it for you) and off you go. It's the same level of support as with VS Code. If you're not new to emacs, maybe consi…

My terminal editor of choice is nano :P

It sounds like you have two editors at least, vscode and nano. Based on this description, I would assume you use nano for commit messages, config file updates, and not much more. If that’s the case, you may want to at least check out what emacs or vim can do for you with some basic lsp integration. These would be replacements for vscode not nano, although once you get used to them, you might switch EDITOR over. Compared to the complexity of systems programming, vim or eMacs should be well within your grasp.

Re: C Macro Reflection in Zig

#74
post #71

Earlier quoted context omitted.

It would actually be nice if the translate-c build system step would also allow some restricted symbol transformation (at least stripping the 'namespace prefix' from C library symbols). For instance Odin allows to define a 'link_prefix' for C APIs which is then stripped from the imported symbols: @(default_calling_convention="c", link_prefix="sg_") This causes name transformations like: sg_setup() => setup() sg_shutd…

> common case-conventions Unfortunately, we must not forget forget ABOMINATIONCase and NAMESPACED_PascalCase (we could also generalize this to any switch from one convention to another after the first word). I've found they usually are, in fact, identifiable and roundtrippable. I've found the following usually works (it fails for multi-word prefixes or non-leading exceptions, and of course single-word identifiers are…

I mean, there can always be a function on the TranslateC step which maps 'special case' names (or even translate them to an entirely different name, for instance when there's collisions with Zig reserved keywords):

    translateSpecialCaseNames(.{
        .{ .src = "ABOMINATIONCase", .dst = "case" },
        .{ .src = "NAMESPACED_PascalCase", .dst = "pascalCase" },
    });
...in my own language bindings generator, being able to define such special case mappings is actually quite important, mainly for handling that situation where an automatic mapping would result in a reserved keyword.

Re: C Macro Reflection in Zig

#75

Earlier quoted context omitted.

See these posts on the LLVM issue by Andrew. They clearly state that this functionality isn't going anywhere, just the method of achieving said functionality is changing: https://github.com/ziglang/zig/issues/16270#issuecomment-161... https://github.com/ziglang/zig/issues/16270#issuecomment-161...

Sounds like damage control. I have to say, for a brilliant guy, andrewrk knows nothing about marketing. The fact that the Zig project can make this significant of a change to their core-value because "trust me i know what I'm doing", makes it impossible (for now) to rely on this in any type of a widely-deployed Enterprise setting. This just made the highly risky move of moving to Zig make it darn near impossible. Wha…

Wait what is controversial here? Removing llvm as a dependency and making it a (probably default available) plugin instead? Seems "obviously good", if you ask me.

Weird machinations around projects that are and aren't (but are privileged because he's the creator) part of the zig foundation would be more concerning, quite frankly.

Re: C Macro Reflection in Zig

#76

Earlier quoted context omitted.

See these posts on the LLVM issue by Andrew. They clearly state that this functionality isn't going anywhere, just the method of achieving said functionality is changing: https://github.com/ziglang/zig/issues/16270#issuecomment-161... https://github.com/ziglang/zig/issues/16270#issuecomment-161...

Sounds like damage control. I have to say, for a brilliant guy, andrewrk knows nothing about marketing. The fact that the Zig project can make this significant of a change to their core-value because "trust me i know what I'm doing", makes it impossible (for now) to rely on this in any type of a widely-deployed Enterprise setting. This just made the highly risky move of moving to Zig make it darn near impossible. Wha…

Unfortunately there's a lot of people on the internet who haven't even used Zig nor plan to use it anytime in the future and who just enjoy to create drama by amplifying any decision with a hint of controversy around it (also see the 'unused variables are errors' drama which turned out to be a non-issue after it was actually implemented).

Unrelated to Zig, it's the exact same thing with "WASM can't access the DOM" btw, comes up everytime when WASM is in the news, but is a complete non-issue in practice for anybody actually using WASM, and I'm sure each popular software project has at least one such 'drama issues'.

The 'LLVM divorce' has been announced waaaay ahead (maybe years) of any actual steps to make that happen, for a language ecosystem that's still unstable anyway, and with the promise that a solution will be in place before LLVM is actually kicked out.

Not sure what else could have been done better, and as other have said, this sort of decision making process is much preferable to a committee approach.

Re: C Macro Reflection in Zig

#77

Earlier quoted context omitted.

This makes the experience more similar to Rust (which I don’t think is bad—it’s just not as unique, smooth, and impressive as the current Zig experience). I’ve been able to convince C programmers to try out and use Zig just due to this unique ability alone, and to be clear, getting C programmers to seriously consider any language other than C is generally very difficult! Having to consider another build system (with…

> This makes the experience more similar to Rust The big difference to the Rust ecosystem (or rather the 'cc' crates.io package which AFAIK is the current standard solution) is that there will be a Clang toolchain package with integrated cross-compilation headers and libraries that is used across all platforms instead of relying on a "platform C/C++ compiler toolchain" - which is the actually brittle part: different…

I truly wish that Rust would steal this from Zig, but I haven't heard any actual interest in it from the project. Oh well. I think it's a real missed opportunity.

https://crates.io/crates/cargo-zigbuild exists though.

Re: C Macro Reflection in Zig

#78

Earlier quoted context omitted.

While I understand the reasoning, I think this is one of the most disappointing decisions by the Zig team. One of the main reasons I took Zig seriously was their C interop story—as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), I was pretty much sold on Zig when I was able to, in a total of I respect Andrew a lot (I…

What's the problem? @cImport is becoming just @import.

@cImport works without build.zig and even with build.zig requires no special configuration (ignoring linking).

As it is currently described, @import of C will require build.zig and specific configuration therein.

Re: C Macro Reflection in Zig

#79
post #57

Earlier quoted context omitted.

The interesting thing is that the Zig build system could be implemented in a C/C++ compiler without any language changes. All that's needed is that (for instance) Clang would have a new option `clang build` which looks for a build.c/cpp file, compiles that into an executable and runs it. The actual build system functionality is 'just' an extension to the stdlib.

It could, but then it would be tied to that specific compiler and the platforms it supports. So is the mess of ISO defined languages, where compiler toolchains are an abstract concept. Also a good point to note that OpenGroup and POSIX never bothered to standardise UNIX package management.

Yeah, just Clang doing its own thing would be useless. It would have to go through the C and C++ committees, at least for the stdlib parts (and this is basically the show stopper for the idea unfortunately).

Re: C Macro Reflection in Zig

#80
post #54

Earlier quoted context omitted.

See these posts on the LLVM issue by Andrew. They clearly state that this functionality isn't going anywhere, just the method of achieving said functionality is changing: https://github.com/ziglang/zig/issues/16270#issuecomment-161... https://github.com/ziglang/zig/issues/16270#issuecomment-161...

Not involved with Zig at all, but this comment is a bit concerning : > This is not the first controversial change I have made to the Zig project, and it won't be the last. I have a vision, and I know how to execute it. People are often surprised by what Zig has accomplished, and they wonder why other projects have not done what Zig does. Well, you are seeing the magic right now. I ignore the peanut gallery and do wha…

I simultaneously understand why that comment gives you pause, and find comfort in seeing such a clear expression of vision.

As someone who often thinks several steps ahead about where I want to take a project, I find it’s just as often difficult to communicate that vision at the level of detail necessary to establish a shared understanding of what those steps mean, and how various apparent minutiae come together to make them all valuable together.

I would be lying if I said I don’t wish I shared this particular hubris, and the corresponding expectation that execution will be sufficient to bolster any trust challenged along the way.

Post reply on HN