Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig's Lovely Syntax

matklad.github.io

Post reply on HN
Print view View original

201–210 of 246 posts

Re: Zig's Lovely Syntax

#201

Post by Y_Y »

Twey wrote: post #195
Y_Y wrote: post #147

Earlier quoted context omitted.

Fair enough. I think it qualifies as "essential complexity" and in my limited experience it's not a common use case and so doesn't make sense to optimize for. In fact in my academic and professional career most of the highly "functional" C that I've come across has been written by me, when I'd rather amuse myself than make something readable. [0] https://en.wikipedia.org/wiki/Essential_complexity

It (this particular example, of function pointer syntax) is absolutely just incidental complexity, though. E.G. Haskell (a -> b) -> c -> d becomes C D (*f(B (*)(A)))(C) and it's no surprise that the former is considered much less fancy than the latter. Of course it's not common — because the language makes it painful :) The causation is the other way around. We've seen in plenty of languages that if first-class funct…

Without curring and closures it certainly will be more painful!

I might write the equivalent signature,

  D f(A, B, C)
and then reorganize things to just pass f around, or make a struct if you really want to bake in your first function.

Re: Zig's Lovely Syntax

#202

Post by WalterBright »

brabel wrote: post #93
WalterBright wrote: post #50

Earlier quoted context omitted.

Zig: const std = @import("std"); D: import std;

I think this is not equivalent because in D, this imports all symbols in the package `std` while in Zig, you just get a "struct" called `std`. I think the equivalent D is: import std=std;

What I wrote is equivalent to the zig declaration. Google says:

    const my_module = @import("my_module.zig");

    This allows you to access pub (public) declarations from my_module.zig through the my_module identifier.

Re: Zig's Lovely Syntax

#203

Post by gf000 »

IshKebab wrote: post #168
gf000 wrote: post #152

Earlier quoted context omitted.

I think Java's solution is much cleaner.

For those of us that haven't used Java for a decade... > In text blocks, the leftmost non-whitespace character on any of the lines or the leftmost closing delimiter defines where meaningful white space begins. From https://blogs.oracle.com/javamagazine/post/text-blocks-come-... It's not a bad option but it does mean you can't have text where every line is indented. This isn't uncommon - e.g. think about code generati…

Why couldn't you have it?

You just put the ending """ where you want it relative to the content.

Re: Zig's Lovely Syntax

#204

Post by drjeats »

qzzi wrote: post #196
IshKebab wrote: post #64

Earlier quoted context omitted.

Maybe if you've never tried formatting a traditional multiline string (e.g. in Python, C++ or Rust) before. If it isn't obvious, the problem is that you can't indent them properly because the indentation becomes part of the string itself. Some languages have magical "removed the indent" modes for strings (e.g. YAML) but they generally suck and just add confusion. This syntax is quite clear (at least with respect to i…

C and Python automatically concatenate string literals, and Rust has the concat! macro. There's no problem just writing it in a way that works correctly with any indentation. No need for weird-strings. " one\n" " two\n" " three\n"

Personally, I'd rather prefix with `\\` than have to postfix with `\n`. The `\\` is automatically prepended when I enter a newline in my editor after I start a multiline string, much like editors have done for C-style multiline comments for years.

Snippet from my shader compiler tests (the `\` vs `/` in the paths in params and output is intentional, when compiled it will generate escape errors so I'm prodded to make everything `/`):

    test "shader_root_gen" {
        const expected =
            \\// Generated file!
            \\
            \\pub const @"spriteszzz" = opaque {
            \\    pub const @"quadsprite" = @import("src\spriteszzz/quadsprite.glsl");
            \\};
            \\
            \\pub const @"sprites" = opaque {
            \\    pub const @"universalsprite" = @import("src\sprites/universalsprite.glsl");
            \\};
            \\
            \\pub const @"simpleshader" = @import("src/simpleshader.glsl");
            \\
        ;

        const cmdline =
            \\--prefix src -o testfile.zig src\spriteszzz/quadsprite.glsl src\sprites/universalsprite.glsl src/simpleshader.glsl
        ;

        var args_iter = std.mem.tokenizeScalar(u8, cmdline, ' ');
        const params = try Params.parseFromCmdLineArgs(&args_iter);

        var buffer: [expected.len * 2]u8 = undefined;
        var stream = std.io.fixedBufferStream(buffer[0..]);
        try generateSource(stream.writer().any(), params.input_files.items, params.prefix);
        const actual = stream.getWritten();

        try std.testing.expectEqualSlices(u8, expected, actual);
    }

Re: Zig's Lovely Syntax

#205

Post by panzerboiler »

Metasyntactic wrote: post #109
kcartlidge wrote: post #62

I much prefer C# 11's raw string literals. It takes the indentation of the first line and assumes the subsequent ones have the same indentation. string json = $""" {title} Welcome to {sitename}. """; And it even allows for using embedded curly braces as real characters: string json = $$""" {{title}} Welcome to {{sitename}}, which uses the {sitename} syntax. """; The $ (meaning to interpolate curly braces) appears twi…

Just a minor correction (as I'm the author of c#'s raw string literal feature). The indentation of the final ` """` line is what is removed from all other lines. Not the indentation of the first line. This allows the first line to be indented as well. Cheers, and I'm glad you like it. I thought we did a really good job with that feature :-)

Did you draw inspiration from Swift's multiline string literal, or was it the other way around? The syntax looks very similar, if not identical.

Re: Zig's Lovely Syntax

#206

Post by pjmlp »

minitech wrote: post #199
pjmlp wrote: post #18

Having @ and .{ } all over the place is hardly lovely, as is having modules like JavaScript's CJS.

There’s nothing wrong with the CommonJS approach except that it’s not designed for static analysis (and whether that was really an issue is debatable). In Zig, it’s compile-time.

For starters being text based for what is supposed to be a systems language, that should support binary distribution.

Re: Zig's Lovely Syntax

#207

Post by minitech »

pjmlp wrote: post #206
minitech wrote: post #199

Earlier quoted context omitted.

There’s nothing wrong with the CommonJS approach except that it’s not designed for static analysis (and whether that was really an issue is debatable). In Zig, it’s compile-time.

For starters being text based for what is supposed to be a systems language, that should support binary distribution.

Supporting binary distribution seems unrelated to the ways in which it’s “like JavaScript’s CJS”, especially in the context of this post about syntax.

Re: Zig's Lovely Syntax

#208

Post by renox »

Cyph0n wrote: post #171
renox wrote: post #158

Earlier quoted context omitted.

Agreed, their reason for not allowing it is weird. No hidden overloading? OK make it explicit then: #+, #/ would be fine.

That would open a can of worms, because then the next thing would use a different symbol. AFAIK, Scala had a huge issue with random symbols polluting code readability.

That's not a reasonable objection, each proposal must be evaluated on its own, not on other non existing future proposal.

Re: Zig's Lovely Syntax

#209

Post by IshKebab »

gf000 wrote: post #203
IshKebab wrote: post #168

Earlier quoted context omitted.

For those of us that haven't used Java for a decade... > In text blocks, the leftmost non-whitespace character on any of the lines or the leftmost closing delimiter defines where meaningful white space begins. From https://blogs.oracle.com/javamagazine/post/text-blocks-come-... It's not a bad option but it does mean you can't have text where every line is indented. This isn't uncommon - e.g. think about code generati…

Why couldn't you have it? You just put the ending """ where you want it relative to the content.

Ah I see - didn't notice it includes the trailing """. Tbh I still prefer Zig's solution. It's more obvious. (Though they should have picked a less intrusive prefix, I'd have gone with a backtick.)

Re: Zig's Lovely Syntax

#210

Post by dminik »

surajrmal wrote: post #200
dminik wrote: post #162

Earlier quoted context omitted.

Ahh, a perfect example of why Zig is uninteresting to me: https://github.com/ziglang/zig/issues/5038#issuecomment-2441... A language hostile to LSP/intellisense.

How is it hostile? The lsp can do type inference just the same as the compiler.

Yes. And by "do type inference just the same as the compiler", that includes having to do comptime execution. Plus with no interfaces/traits/concepts and comptime being mostly any-typed makes it difficult to have helpful intellisense.
Post reply on HN