Hardcoded proofs should be assigned well-named identifiers. If you ever have to alter them, you don't want to be rummaging around your lemmas and corollaries.
On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote: > > Ok. That "haha" was merely to show that no animosity was borne. And also > because you didn't really answer the question as I asked (by quoting the > spec) which I found funny. > > Alas, I guess we couldn't see eye to eye. > > But chill a little bit. I have given all the hardcoded proofs and people > have just given me *feelings* about what they thought should be right. I > think I have the right to disagree. > > Anyway, I can only wish you good continuation. :) > > > On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote: >> >> I'm sorry but your attitude is counterproductive to the discussion. >> "haha" what? I told you I see your point, I think I know the specs very >> well, thank you for the link. >> However, you seem incapable of accepting, despite an number of others >> saying the contrary, despite, given a reasonable example where even the >> standard library gets this "wrong" (according to you, according to me it's >> exactly as it should be). >> You've been explained several times that both point of views hold valid >> arguments so why do you insist your point of view is the only correct one >> and everyone else is wrong? >> The authors of the language which have far more experience that me (I >> can't speak for your experience or others), couldn't get to an agreement on >> how this should work so they took the best decision, let the user deal with >> this according to their individual needs. >> I'll stop following this thread / replying as it's pointless to do so at >> this point. >> Good luck proving everyone else is wrong and you know better. >> >> On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote: >>> >>> Ok, Let me help you out haha :) >>> >>> Here is the definition of a slice. It is not a container. >>> https://golang.org/ref/spec#Slice_types >>> >>> I am not inventing things. >>> >>> I know what people on this thread said, but that's their misconception. >>> >>> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote: >>>> >>>> As you pointed out, Printf() should follow the ref spec but that >>>> doesn't happen because some humans don't perceive this accuracy as >>>> necessary or maybe because the way to resonate about slices / arrays is as >>>> containers for the actual values. >>>> Thus we have Printf working as it does (and %p will indeed print the >>>> memory address of the slice type). >>>> >>>> I would definitely want to be able to compare []int{1, 2, 3} with >>>> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example >>>> purposes but think of them as coming from different sources) >>>> Apparently you don't, and that's fine. >>>> >>>> That's exactly why the compiler only allows comparison with nil, to >>>> force the user to think about that should be compared, not do it by >>>> default >>>> and have potential hidden issues that might be uncovered too late in the >>>> process. >>>> >>>> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote: >>>>> >>>>> In fact, that is somewhat my fault. >>>>> >>>>> I should ask: >>>>> >>>>> What is a slice? >>>>> What is an array? >>>>> >>>>> Spoiler: a slice is a reference type in its "wikipedia-ish" definition >>>>> (auto-dereferencing) which is the reason you observe such a result in the >>>>> playground. >>>>> >>>>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote: >>>>>> >>>>>> No. You should not get it from here. You should get the answer from >>>>>> the spec. Let alone the fact that the implementation should ideally >>>>>> follow >>>>>> the spec and not the reverse. >>>>>> >>>>>> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote: >>>>>>> >>>>>>> If I look at what %v means, print out the values of various types in >>>>>>> Go, according to https://golang.org/pkg/fmt/ then I believe that >>>>>>> this holds the answer: https://play.golang.org/p/GiLckoBDxa >>>>>>> >>>>>>> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote: >>>>>>>> >>>>>>>> Not for comparison. >>>>>>>> >>>>>>>> I am just asking what is the value of a slice and what is the value >>>>>>>> of an array. >>>>>>>> >>>>>>>> Remember that there is no slice comparison that has been spec'ed so >>>>>>>> far. >>>>>>>> >>>>>>>> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote: >>>>>>>>> >>>>>>>>> For []T the value of a slice for the purpose of comparison would >>>>>>>>> be each individual value compared against each-other (ofc maybe >>>>>>>>> comparing >>>>>>>>> the length first as an optimization). >>>>>>>>> Same goes for an array. >>>>>>>>> >>>>>>>>> And again, you are missing the whole point. Both me and you are >>>>>>>>> wrong in each-others points of view. >>>>>>>>> Just accept this. >>>>>>>>> >>>>>>>>> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote: >>>>>>>>>> >>>>>>>>>> What's the value of a slice? >>>>>>>>>> >>>>>>>>>> What's the value of an array? >>>>>>>>>> >>>>>>>>>> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote: >>>>>>>>>>> >>>>>>>>>>> If the type is *[]T then comparing memory addresses make sense >>>>>>>>>>> to see if both terms point to the same memory address. >>>>>>>>>>> If the type is []T then comparing memory addresses doesn't make >>>>>>>>>>> sense as I'd expect to compare values. >>>>>>>>>>> Finally, if the type is []*T then I'd still expect to compare >>>>>>>>>>> values (even if this is inconsistent with the above two rules), >>>>>>>>>>> mainly >>>>>>>>>>> because I'm usually interested in the values a slice holds. >>>>>>>>>>> >>>>>>>>>>> And that's exactly why Ian and others said this is complicated >>>>>>>>>>> to define as different users expect different outcomes. >>>>>>>>>>> So rather than deal with this, in an auto-magic way, better let >>>>>>>>>>> the users deal with it as they see fit from case to case. >>>>>>>>>>> >>>>>>>>>>> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote: >>>>>>>>>>>> >>>>>>>>>>>> Which is why it should be formalized. >>>>>>>>>>>> >>>>>>>>>>>> Where is the inconsistency between slices and arrays? >>>>>>>>>>>> Why do people even think that a slice need to behave like an >>>>>>>>>>>> array wrt equality, were it introduced? >>>>>>>>>>>> >>>>>>>>>>>> A slice is not an array! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as....@gmail.com >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Relaxing unformalized behavior makes little sense to me. >>>>>>>>>>>>> Explaining why equality is inconsistent between slices and arrays >>>>>>>>>>>>> is not >>>>>>>>>>>>> something I want to do either. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rob and Robert actually wrote that this area of the spec >>>>>>>>>>>>>> needs more work... >>>>>>>>>>>>>> Otherwise, the behaviour of maps, slices and funcs cannot be >>>>>>>>>>>>>> fully explained. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as....@gmail.com >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Go does not have reference types. As far as I know, the word >>>>>>>>>>>>>>> was purposefully removed from the spec to remove the ambiguity >>>>>>>>>>>>>>> surrounding >>>>>>>>>>>>>>> the word. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> @Martin >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I've mentioned earlier, one ought to be careful about >>>>>>>>>>>>>> false friends from other languages. >>>>>>>>>>>>>> I am not sure I understand what you mean by: >>>>>>>>>>>>>> >>>>>>>>>>>>>> if the name field is changed after the call >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
