4 ms·
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, th
by TwentyPosts 3y ago
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!
- ljlolel 3y agoIdea: 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
- spenczar5 3y agoWriting 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.
- kps 3y ago∇ 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.
- deleted 3y ago[deleted]
- renox 3y ago> 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.
- thechao 3y agoMaybe 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)
- MH15 3y agoHuh I've never seen this approach. Very interesting solution, could be adapted to the JavaScript matrix libraries I bet.
- thechao 3y agoThis is how TeX handles math — the "$" operator is an "inline" version of the same.
- estebank 3y agoIn 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.
- bakkoting 3y agoThere'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 https://github.com/tc39/proposal-operator-overloading