Hacker News Reader

Comment by pixelpoet | Hacker News Reader

I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding.

Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for vector stuff (ideally with swizzles); same for all the shading languages.

Perhaps it's doable to make a little domain-specific language (DSL) in Zig for this purpose?

With vector extensions (and as floh [hi!] points out, also matrices please) I'm 100% ready to seriously consider transitioning from C++, given the smooth C integration.

View on HN

Last year I dabbled in making a DSL like solution for operator overloading: https://github.com/Laremere/alg

It ends up slightly more verbose in usage, but the statements themselves remain concise. Unfortunately I got a real job that isn't using Zig, so I've stopped working on this. Others can feel free to take up the torch, though.

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.

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.

> What was the language which used backticks to transform any function into an infix binary operator? Ruby? Perl?

Haskell.

Haskell does this.

Racket

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)

    @"..."(a, b)

+1 (don't want general operator overloading, but a more powerful @Vector builtin type, basically Clang's ext_vector_type: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...), plus maybe a similar @Matrix builtin up to 4x4.

I think operator overloading should be fine even for puritans, as long the language requires the type to be numerical in a strict sense, and so they have a well defined semantics. So integers, floating point, complex numbers, vectors, matrices, etc.

How would the language require it to be numerical? For example, if you're defining complex numbers in a library, what would the compiler be checking about your ComplexNumber type before allowing you to define `+` for it?

A few ways. The compiler could enforce commutativity, associativity and other properties of those operators.

Another possible route is to require that all types contained within the exported types are also numerical, or have some specific set of operators defined.

Do you mean at the type level or also for the operational semantics? In the latter case it's undecidable.

Also, you mentioned matrices in the previous comment, but multiplication between matrices is not commutative.

It's undecidable if the language used to define operators is sufficiently expressive. Even simple syntactic constraints would work well enough for most scenarios, like "operators may only be defined by an expression containing other operators".

New types also don't have to inherit the properties of the operators they use.

In any case, my point was that there are multiple avenues to explore in providing operators in a way that don't compromise the compiler's ability to optimize numerical code.

The problem with operator overloading is not really numericity, IMO. The problems are:

- hidden control flow (function calls should look like function calls, an operation should never mask a function call)

- global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.

You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial

Multiplication takes more than a handful of instructions if the hardware doesn't do it.

https://godbolt.org/z/ccYPaz1Pj

For this example (AVR), this is the int multiply function __mulhi3:

    00: 00 24  eor  r0, r0
    02: 55 27  eor  r21, r21
    04: 00 c0  rjmp .+0
    06: 08 0e  add  r0, r24
    08: 59 1f  adc  r21, r25
    0a: 88 0f  add  r24, r24
    0c: 99 1f  adc  r25, r25
    0e: 00 97  sbiw r24, 0x00
    10: 01 f0  breq .+0
    12: 76 95  lsr  r23
    14: 67 95  ror  r22
    16: 00 f0  brcs .+0
    18: 71 05  cpc  r23, r1
    1a: 01 f4  brne .+0
    1c: 80 2d  mov  r24, r0
    1e: 95 2f  mov  r25, r21
    20: 08 95  ret

I mean, pedantically speaking the normal zig operators do control flow in their operators, in checked mode they panic on overflow, etc (you're not supposed to recover from them but I suppose it's possible). There's probably (internal) control flow in the saturating operators, etc.

Not always. I’ve seen division and atomic operations stay as function calls to libgcc. However, semantics of these are well-defined either way, unlike user-defined operators, so existence of a hidden call is at most an inconvenience when linking code from different compilers.

> - hidden control flow (function calls should look like function calls, an operation should never mask a function call)

You can restrict operator definitions to expressions containing other operators. Operators are now guaranteed to expose only as much control flow as the underlying operators would already expose.

> - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

I'm not sure what you mean. Behaviour depends on language semantics. You don't specify why operators are uniquely weird on this compared to literally any other function call when language semantics or library behaviour changes.

Your atomic increment may turn into a function call if it’s targeting multiple microarchitectures.

> hidden control flow (function calls should look like function calls, an operation should never mask a function call)

An operator is either a function call or some simple built-in operation.

Thus not hidden.

That syntactic elements that consist of symbols rather than alnum and that are used as prefix or infix operators are necessarily “not a function call” is just a rule that can be changed.

> An operator is either a function call or some simple built-in operation.

In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is.

It's like a self-driving car that's safe 99.999% of the time but still requires you to continuously pay attention to take over at a second's notice.

Humans just don't work like that.

> In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is.

Noo it isn’t. Many languages use something like `+` for string concatenation. Maybe list concatenation.

Maybe I'm small brained but built in vector types align with heavily platform optimized libraries. Meaning you don't want this stuff implemented in the compilers front end. You want it handled in the compilers back end.

Performance is equivalent in both representations, but the important thing is being able to write

  vec4 c = a * 4 + b;

instead of

  vec4 c = vec4_add(vec4_mul(a, 4), b);

i.e. infix vs postfix order, with simple * and +/- operators etc. I would very much like to appeal to the Zig authors to see the beauty in the former expression compared to the latter, for a huge class of real-world mathematical applications.

If this wasn’t math code we’d refactor such code into helper functions, but somehow when it’s math we refuse to.

vec4 c = a * 4 + b;

vec4 c = vec4_add(vec4_mul(a, 4), b);

vec4 c = vec4_fma(4, a, b);

Are Clang’s builtin types interoperable with __m128 intrinsics?

Mathematics is such an unprincipled mess of DSLs. I wonder why math domains always come up as the sticking point with the caveat of “but not operators for anything else, though”.

It would be nice, for sure, to be able to define some infix combinators.

Anyway, it’s bad enough that arithmetic has pressured almost all programming languages to adopt operator precedence. (No operator precedence other than either go-left or go-right is so much simpler. Which would also mitigate some of the complaining about custom operators since then they just become infix functions.)

I agree with you on a theoretical level, but arguably we should not be the ones to bear the complexity of that decision — the representation of a given data is very important for our “limited” human brains.

I think the major problem here is shoehorning everything into a “symbol soup” on a 2D matrix. I do get that it has plenty advantages (can be typed without special program, easier version control, etc), but I would like to see a resurrection of interest in visual language. I’m not meaning something as visual as scratch or so, but some special blocks could come in handy.

As a comptime macro, yes, you should be able to slot in a DSL for all your vector math and essentially "pass in a string, get the function calls back". It would not be that hard, if you're up on your parser-writing skills, and definitely much cleaner than any C-style equivalent.

Yep that seems comptime possible but a little heavy handed with string work, no? With everyone writing their own parsers and language tools...

In any case, if something practical is done here I'd be interested. Aesthetically I prefer the "vectors and matrices are first class types" (and maybe complex numbers could be too), but I guess Andrew isn't so sympathetic to these types being part of the standard language :/

There's a proposal for complex numbers: https://github.com/ziglang/zig/issues/16278

Vectors are already first-class types via @Vector, aren't they?

Whoa, I haven't been keeping up to date about this, there seems to be good related discussion here: https://github.com/ziglang/zig/issues/7295

I'll hope for some future news of Zig having vector and complex number support! It will be a great day for fast ray/path tracers :)

Unfortunately, vectors in Zig are the kind you use in SIMD and not in graphics programming. Perhaps there's some overlap, but I'm unfamiliar with both fields so I can't say to what degree.

It would be nicer still if vectors and matrices were first class citizens. That way you can hide all of that stuff and it opens up across the board optimization routes that are otherwise much harder.

Agreed, that's basically what I'm asking/begging; don't need operator overloading, but please do give me vectors and matrices.

Edit: I asked in the Zig Discord and was told "it's been denied many times", oh well :/ Fair enough, it's their language to control.

That's a weird answer. If something is denied many times that shouldn't count as a reason to deny it again but to question whether that denial is appropriate.

Odin does this afaik.

Not all that useful but fun: you can implement swizzling with comptime

Reply on news.ycombinator.com