Most active commenters

    ←back to thread

    Zig is hard but worth it

    (ratfactor.com)
    401 points signa11 | 13 comments | 01 Jun 23 10:44 UTC | HN request time: 0.771s | source | bottom
    Show context
    jsheard ◴[01 Jun 23 12:51 UTC] No.36150389[source]▶
    I get what Zig is going for in making all operations as explicit as possible, but I fear that it's going to turn away fields like graphics and game development where it would be a good fit except for the lack of operator overloading forcing you to go back to C-style math function spaghetti. It's all fun and games until what should be a straightforward math expression turns into 8 nested function calls.
    replies(8): >>36150475 #>>36150541 #>>36150795 #>>36150946 #>>36151013 #>>36151746 #>>36151792 #>>36152172 #
    1. TwentyPosts ◴[01 Jun 23 13:07 UTC] No.36150541[source]▶
    I am not much of a Zig-head, but the best compromise I can think of is having a few operators which purely and solely exist for this purpose. In other words, there is no operator overloading, but you can define, say, "#+" for any two structs, or something like that.

    So if you want to encode matrix multiplication, then you'll always have to write `mat1 #* mat2`. This feels like a hack, and isn't all that elegant, but it'd be clear that every usage of such an operator is a disguised function call. (And according to what Andrew Kelley said, it's all about not hiding function calls or complex operations in seemingly innocent 'overloaded' symbols.)

    If you want to take this one step further you'd probably have to allow users to define infix functions, which would be its own can of worms.

    Honestly, I am not particularly happy with any of these ideas, but I can't think of anything better either!

    replies(3): >>36150784 #>>36153058 #>>36153273 #
    2. ljlolel ◴[01 Jun 23 13:31 UTC] No.36150784[source]▶
    Idea: allow some weird Unicode operators like Julia does. Then it’ll be clear the weird operator is doing something weird and new. And this already works in other languages. There are lots of Unicode
    replies(1): >>36151239 #
    3. spenczar5 ◴[01 Jun 23 14:10 UTC] No.36151239[source]▶
    Writing greek symbols is sufficiently annoying that I always kind of resent code that does this. It’s not just about the first time you are writing code, but also when you are reviewing it, or trying to share a snippet with a coworker, or lots more scenarios. Maybe it’s just me, but writing ‘z = x ∇ d’ is really tedious.
    replies(2): >>36153390 #>>36156259 #
    4. renox ◴[01 Jun 23 16:00 UTC] No.36153058[source]▶
    > I am not much of a Zig-head, but the best compromise I can think of is having a few operators which purely and solely exist for this purpose. In other words, there is no operator overloading, but you can define, say, "#+" for any two structs, or something like that.

    And those operators wouldn't have any precedence.

    > If you want to take this one step further you'd probably have to allow users to define infix functions, which would be its own can of worms.

    As long as these infix function are preceded by a recognizable operator ("#" in your example), I think that this would be fine.

    5. thechao ◴[01 Jun 23 16:13 UTC] No.36153273[source]▶
    Maybe an operator-overloading region?

        #{
       m3 = m1 * m2 + m3;
       m3 += m4;
    }
    Basically, pure syntactic sugar to help the author express intent without having to add a bunch of line-chatter.

    Speaking of operator-overloading, I really wish C++ (anyone!) had a `.` prefix for operator-overloading which basically says "this is more arguments for the highest-precedence operator in the current expression:

        a := b * c .+ d;
    Which translates to:

        a := fma(b, c, d)
    replies(1): >>36154201 #
    6. kps ◴[01 Jun 23 16:20 UTC] No.36153390{3}[source]▶
    ∇ is near-worst-case since it's not even Greek. I think domain-specific keyboard layouts are as much of a good idea as language-specific layouts, but they're a nuisance to install on *nix (trivial on OS X). Using .XCompose is the most practical *nix approach, in the absence of program-specific methods like Julia's tab-completable backslash names.
    replies(2): >>36154436 #>>36156298 #
    7. MH15 ◴[01 Jun 23 17:12 UTC] No.36154201[source]▶
    Huh I've never seen this approach. Very interesting solution, could be adapted to the JavaScript matrix libraries I bet.
    replies(3): >>36154476 #>>36154965 #>>36157284 #
    8. Conscat ◴[01 Jun 23 17:26 UTC] No.36154436{4}[source]▶
    I interpret this as meaning that ibus is difficult to set up. FWIW, Emacs and Kitty let you input unicode without it.
    9. thechao ◴[01 Jun 23 17:29 UTC] No.36154476{3}[source]▶
    This is how TeX handles math — the "$" operator is an "inline" version of the same.
    10. estebank ◴[01 Jun 23 18:05 UTC] No.36154965{3}[source]▶
    In Rust you could use a proc macro that parsed the block and translates the token to a new token stream that uses method calls with the appropriate operator precedence, for arbitrary operations you could want to define. You're effectively writing a compiler plugin and language extension at that point. For targeted niche domains, this might be worthwhile.
    11. ◴[01 Jun 23 19:37 UTC] No.36156259{3}[source]▶
    12. lvass ◴[01 Jun 23 19:40 UTC] No.36156298{4}[source]▶
    Just use C-x 8 in Emacs and you'll get any symbol by name, with autocomplete.
    13. bakkoting ◴[01 Jun 23 21:03 UTC] No.36157284{3}[source]▶
    There's a not-very-active proposal to add operator overloading to JS which takes a similar scoped approach:

    https://github.com/tc39/proposal-operator-overloading