4 ms·

There is no "just work" for deep equality. The standard library would have to make decisions on behalf of the application that it has no business making. I can

There is no "just work" for deep equality. The standard library would have to make decisions on behalf of the application that it has no business making. I can tell you right now that while there will be many upcoming language changes, none of them will be comfy to Python programmers. Zig is very much an imperative language. Or perhaps think of it as a declarative DSL for outputting machine code.

_a_a_a_ 4y ago
> a declarative DSL for outputting machine code and thanks for the laugh
codethief 4y ago
Thanks for your message, Andrew! Just to be clear, I didn't mean any offense and maybe my critique wasn't as well-balanced as it could have been. So far, coding in Zig has been a fun ride, despite the occasional obstacles I've run into! > There is no "just work" for deep equality Say I have two variables A and B of the same struct type. Each points to a finite region in memory of the same size. Why can't I just compare these two regions using `A == B` to make sure they are equal? Yes, one can obviously come up with alternative definitions of what equality might mean for structs (only compare certain subfields etc.) but wouldn't the aforementioned definition be a good default that would work in the majority of cases? Alternatively, there is `std.testing.expectEqualDeep()` which walks through all fields but as far as I know there is no equivalent for production code(?) > none of them will be comfy to Python programmers Oh I think the multi-sequence for loops feature already makes Zig more comfy! :) Just to be clear: I wouldn't want Zig to be another Python. While I like Python from a developer experience POV, it is dictionaries and magic methods all the way down and often unnecessarily slow and complex. I still think one could find a good balance between DX and full low-level control, though. One could e.g. have one convenient way to express a certain problem that gives you medium control over performance (e.g. the `==` example above) and one or more fine-tuned, but possibly less concise ways of expressing the problem that provide full control but require more lines of code. In the struct equality example the latter would mean defining some kind of `eql()` function that would be optimized to the struct type (e.g. compare certain fields first as they are more likely to differ etc.). Would this violate the Zen of Zig?[0] > Only one obvious way to do things. After all, there is also > Favor reading code over writing code Right now, at least, I often run into situations where I don't know of any obvious way to solve my problem. Then I end up writing lengthy code to tell Zig what I want and end up with code that's so-so on the fun-to-read scale. [0]: https://ziglang.org/documentation/master/#Zen https://ziglang.org/documentation/master/#Zen
- munificent 4y ago
  > Why can't I just compare these two regions using `A == B` to make sure they are equal? Why is shallow equality useful? You could have `A == B` be true, but then as soon as you wrap pointers to them in C and D, now `C == D` is false.
  - shagie 4y ago
    It gets into even more fun if A has a pointer to C has a pointer to B, and B has a pointer to D has a pointer to A.
  - codethief 4y ago
    > > Why can't I just compare these two regions using `A == B` to make sure they are equal? > Why is shallow equality useful? Of course deep equality checks are useful, too, I'm not denying that. But in many cases you are not dealing with several layers of structs nested through pointers. You just want to compare simple structs and be done with it, without having to write an eql() function for every single case. Besides, many other operations in Zig operate directly on the memory, so why should == be any different?
- deleted 4y ago
  [deleted]
cultureswitch 4y ago
Deep equality is easy as long as the user has properly implemented it for all the types involved. Standard libraries implementing deep equality correctly on standard collections should really not be a problem at all.
- deleted 4y ago
  [deleted]
codethief 4y ago
I need to correct myself: I only realized now that in my original message I put "deep equality" where it had no business of being. I meant to write "equality" or "shallow equality", i.e. simple comparison of the memory regions the variables represent, as outlined in my other response to you. My apologies for the confusion!

_a_a_a_ 4y ago

> a declarative DSL for outputting machine code and thanks for the laugh

codethief 4y ago

Thanks for your message, Andrew! Just to be clear, I didn't mean any offense and maybe my critique wasn't as well-balanced as it could have been. So far, coding in Zig has been a fun ride, despite the occasional obstacles I've run into! > There is no "just work" for deep equality Say I have two variables A and B of the same struct type. Each points to a finite region in memory of the same size. Why can't I just compare these two regions using `A == B` to make sure they are equal? Yes, one can obviously come up with alternative definitions of what equality might mean for structs (only compare certain subfields etc.) but wouldn't the aforementioned definition be a good default that would work in the majority of cases? Alternatively, there is `std.testing.expectEqualDeep()` which walks through all fields but as far as I know there is no equivalent for production code(?) > none of them will be comfy to Python programmers Oh I think the multi-sequence for loops feature already makes Zig more comfy! :) Just to be clear: I wouldn't want Zig to be another Python. While I like Python from a developer experience POV, it is dictionaries and magic methods all the way down and often unnecessarily slow and complex. I still think one could find a good balance between DX and full low-level control, though. One could e.g. have one convenient way to express a certain problem that gives you medium control over performance (e.g. the `==` example above) and one or more fine-tuned, but possibly less concise ways of expressing the problem that provide full control but require more lines of code. In the struct equality example the latter would mean defining some kind of `eql()` function that would be optimized to the struct type (e.g. compare certain fields first as they are more likely to differ etc.). Would this violate the Zen of Zig?[0] > Only one obvious way to do things. After all, there is also > Favor reading code over writing code Right now, at least, I often run into situations where I don't know of any obvious way to solve my problem. Then I end up writing lengthy code to tell Zig what I want and end up with code that's so-so on the fun-to-read scale. [0]: https://ziglang.org/documentation/master/#Zen https://ziglang.org/documentation/master/#Zen

munificent 4y ago
> Why can't I just compare these two regions using `A == B` to make sure they are equal? Why is shallow equality useful? You could have `A == B` be true, but then as soon as you wrap pointers to them in C and D, now `C == D` is false.
- shagie 4y ago
  It gets into even more fun if A has a pointer to C has a pointer to B, and B has a pointer to D has a pointer to A.
- codethief 4y ago
  > > Why can't I just compare these two regions using `A == B` to make sure they are equal? > Why is shallow equality useful? Of course deep equality checks are useful, too, I'm not denying that. But in many cases you are not dealing with several layers of structs nested through pointers. You just want to compare simple structs and be done with it, without having to write an eql() function for every single case. Besides, many other operations in Zig operate directly on the memory, so why should == be any different?
deleted 4y ago
[deleted]

cultureswitch 4y ago

Deep equality is easy as long as the user has properly implemented it for all the types involved. Standard libraries implementing deep equality correctly on standard collections should really not be a problem at all.

deleted 4y ago
[deleted]

codethief 4y ago

I need to correct myself: I only realized now that in my original message I put "deep equality" where it had no business of being. I meant to write "equality" or "shallow equality", i.e. simple comparison of the memory regions the variables represent, as outlined in my other response to you. My apologies for the confusion!