7 ms·
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
by pixelpoet 3y ago
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.
- flohofwoe 3y ago+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-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...), plus maybe a similar @Matrix builtin up to 4x4.
- xgkickt 3y agoAre Clang’s builtin types interoperable with __m128 intrinsics?
- Gibbon1 3y agoMaybe 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.
- pixelpoet 3y agoPerformance 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.
- eska 3y agoIf 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);
- naasking 3y agoI 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.
- justinpombrio 3y agoHow 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?
- naasking 3y agoA 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.
- SkiFire13 3y agoDo 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.
- naasking 3y agoIt'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.
- 3y ago
- chongli 3y agoDon’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.
- luckystarr 3y agoWhat 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.
- chrisoverzero 3y ago> What was the language which used backticks to transform any function into an infix binary operator? Ruby? Perl? Haskell.
- tyg13 3y agoHaskell does this.
- rscho 3y agoRacket
- throwawaymaths 3y agoI 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)
- quic5 3y agoNot all that useful but fun: you can implement swizzling with comptime
- syntheweave 3y agoAs 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.
- pixelpoet 3y agoYep 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 :/
- defen 3y agoThere's a proposal for complex numbers: https://github.com/ziglang/zig/issues/16278 https://github.com/ziglang/zig/issues/16278 Vectors are already first-class types via @Vector, aren't they?
- pixelpoet 3y agoWhoa, 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 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 :)
- paoda 3y agoUnfortunately, 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.
- jacquesm 3y agoIt 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.
- pixelpoet 3y agoAgreed, 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.
- jacquesm 3y agoThat'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.
- Laremere 3y agoLast year I dabbled in making a DSL like solution for operator overloading: https://github.com/Laremere/alg 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.
- dsego 3y agoOdin does this afaik.
- avgcorrection 3y agoMathematics 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.)
- kaba0 3y agoI 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.