News for hackers. Stuff that matters.
Re:Problems of C, and how Zig addresses them by chongli on Monday July 03, 2023 @02:34PM (#36577089)
Don’t even need operator overloading for vectors/matrices. It would be fine if we could simply define new operators (functions with infix notation) and use those. This would allow us to define an operator for matrix multiplication, matrix-vector product, dot product, and cross product.

Having to define these operators as functions with unique text names is extremely ugly and serves no purpose that I can see.

Re:Problems of C, and how Zig addresses them by luckystarr on Monday July 03, 2023 @02:53PM (#36577329)
What was the language which used backticks to transform any function into an infix binary operator? Ruby? Perl?

Something like this could actually fulfill Andrews goal of not having any hidden control flow, as the function would be plainly visible.

The other thing of course would be, what then the valid function names would be? Definitely not `*` but probably `×` or whatever.

Re:Problems of C, and how Zig addresses them by chrisoverzero on Monday July 03, 2023 @03:05PM (#36577442)
> What was the language which used backticks to transform any function into an infix binary operator? Ruby? Perl?

Haskell.

Re:Problems of C, and how Zig addresses them by tyg13 on Monday July 03, 2023 @03:06PM (#36577457)
Haskell does this.
Re:Problems of C, and how Zig addresses them by rscho on Monday July 03, 2023 @03:12PM (#36577526)
Racket
Re:Problems of C, and how Zig addresses them by throwawaymaths on Monday July 03, 2023 @07:16PM (#36580053)
I think the change could be as limited as a change to the parser. You could also enforce hygenicity (limiting scope only to places where it is asked for) by requiring it to be

    const @"..." = @import("my_operator.zig").add;
For example. Then in the code the parser transforms

    (a ... b)
to

    @"..."(a, b)