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

191–200 of 246 posts

Re: Zig's Lovely Syntax

#191

Post by ivanjermakov »

steveklabnik wrote: post #185
ivanjermakov wrote: post #172

Earlier quoted context omitted.

If I understood `abort` semantics correctly, it has a type of `never` or Rust's `!`. Which has a meaning "unobtainable value because control flow went somwhere else". `void` is closer to `unit` or `()` because it's the type with no allowed values. Cool trick: some languages (e.g. TypeScript) allow `void` generics making parameters of that type optional.

Unit has exactly one allowed value.

Right, but there is not much semantic difference in having one or having zero allowed values.

Re: Zig's Lovely Syntax

#192

Post by NobodyNada »

ivanjermakov wrote: post #191
steveklabnik wrote: post #185

Earlier quoted context omitted.

Unit has exactly one allowed value.

Right, but there is not much semantic difference in having one or having zero allowed values.

There's a huge semantic difference: a type with zero allowed values can never be constructed.

This means that a function that returns an uninhabited type is statically known to not return -- since there's no way it could construct an uninhabited value for a return expression. It also means you can coerce a value of uninhabited type into any other type, because any code which recieves a value of an uninhabited type must be unreachable.

For instance, in Rust you can write the following:

    let weekday_name: &str = match weekday_number {
        1 => "Sunday",
        2 => "Monday",
        3 => "Tuesday",
        4 => "Wednesday",
        5 => "Thursday",
        6 => "Friday",
        7 => "Saturday",
        i => panic!("invalid weekday number: {i});
    };
Because panic! aborts the program and doesn't return, its return type is uninhabited. Thus, a panic! can be used in a context where a string is expected.

Re: Zig's Lovely Syntax

#193

Post by flexagoon »

conaclos wrote: post #188
z_open wrote: post #54

> Raw or multiline strings are spelled like this: const still_raw = \\const raw = \\ \\Roses are red \\ \\ Violets are blue, \\ \\Sugar is sweet \\ \\ And so are you. \\ \\ \\; \\ ; This syntax seems fairly insane to me.

I like the idea of repeating the delimiter on every line. However `//` looks like a comment to me. I could simply choose double quote: const still_raw = "const raw = " "Roses are red " " Violets are blue, " "Sugar is sweet " " And so are you. " " "; " ; This cannot be confused with a string literal because a string literal cannot contain newline feeds.

What if you have something like

    const raw =
        "He said "Hello"
        "to me
    ;
Wouldn't that be a mess to parse? How would you know that "He said " is not a string literal and that you have to continue parsing it as a multiline string? How would you distinguish an unclosed string literal from a multiline string?

Re: Zig's Lovely Syntax

#194

Post by seabombs »

z_open wrote: post #54

> Raw or multiline strings are spelled like this: const still_raw = \\const raw = \\ \\Roses are red \\ \\ Violets are blue, \\ \\Sugar is sweet \\ \\ And so are you. \\ \\ \\; \\ ; This syntax seems fairly insane to me.

I think the syntax highlighting for this could make it more readable. Make the leading `\\` a different color to the string content.

Re: Zig's Lovely Syntax

#195

Post by Twey »

Y_Y wrote: post #147
Twey wrote: post #145

Earlier quoted context omitted.

I maintain — they shouldn't be fancy. ‘Fancy’ is the mark of something your language doesn't support well. They can be _long_, and that's often worth breaking up, but if something is ‘fancy’ it's because it's not clear to read, so you should attach some identifier to it that explains what it's supposed to mean. That's significantly, though not exclusively, a function (ha) of the syntax used to express the concept. If…

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 functions are ergonomic to use then people use them all over the place.

Re: Zig's Lovely Syntax

#196

Post by qzzi »

IshKebab wrote: post #64
z_open wrote: post #54

> Raw or multiline strings are spelled like this: const still_raw = \\const raw = \\ \\Roses are red \\ \\ Violets are blue, \\ \\Sugar is sweet \\ \\ And so are you. \\ \\ \\; \\ ; This syntax seems fairly insane to me.

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"

Re: Zig's Lovely Syntax

#197

Post by Twey »

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…

Right, this is a pretty common syntax, but doesn't address the same problem as Zig's syntax.

I've only seen two that do: the Zig approach, and a postprocessing ‘dedent’ step.

Re: Zig's Lovely Syntax

#199

Post by minitech »

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.

Re: Zig's Lovely Syntax

#200

Post by surajrmal »

dminik wrote: post #162
do_not_redeem wrote: post #13

Earlier quoted context omitted.

Zig is planning to get rid of explicit `T{}` syntax, in favor of only supporting inferred types. https://github.com/ziglang/zig/issues/5038 So the explanation of a dot standing in for a type doesn't make sense in the long run.

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.
Post reply on HN