Thank you for encouraging words about generic in spec. Knowing that much more skilled people than I also have problem with understanding this part of spec, give my self assessment a boost.
sobota, 10 czerwca 2023 o 21:44:22 UTC+2 Axel Wagner napisał(a): > If it helps, I don't think I really understand the generics parts of the > spec myself. > > On Sat, Jun 10, 2023 at 7:13 PM Kamil Ziemian <kziem...@gmail.com> wrote: > >> This is not a complaint, but a reflection. I have read, as careful as I >> can, the half of the Go Spec and if I didn't learn how parametric >> polymorphism (generics; did I spell it right) should work from proposals >> and talks on YouTube, I would probably understand 30% less from it. I know >> that how parametric polymorphis works in Go and how is described in Spec is >> not in 100% identical with proposals, but it is good enough. Due to them I >> have overall picture of what type parameters and related concepts are, so I >> can guess what is the intention behind part of the Spec that mention type >> them. >> >> I think I just wouldn't be able learn parametric polymorphism from >> reading Spec. Things related to it are scattered across the text (this is >> not a complaint, I just notice a fact) and gathering them together is not a >> easy task. >> >> I should note, that I want to use parametric polymorphism as really as >> possible. For me this is a feature of the last resort, but one that you >> should know that exists. >> >> Needless to say, I will need to read Spec one more time in the future, at >> least. >> >> Best regards, >> Kamil >> >> sobota, 3 czerwca 2023 o 23:48:52 UTC+2 Sean Liao napisał(a): >> >>> It is not a typo >>> >>> https://go.dev/issue/24451 >>> >>> - sean >>> >>> >>> On Sat, Jun 3, 2023 at 10:05 PM peterGo <go.pe...@gmail.com> wrote: >>> >>>> It's a simple typo. Send in a fix. >>>> >>>> peter >>>> >>>> On Saturday, June 3, 2023 at 4:07:15 PM UTC-4 Kamil Ziemian wrote: >>>> >>>>> As burak serdar said, 9 = 3 * 3 is not a prime number, all other >>>>> elements in the slice are prime numbers. It looks like authors of Go Spec >>>>> want to make a joke or check how well people read examples in it. >>>>> >>>>> Best regards, >>>>> Kamil >>>>> sobota, 3 czerwca 2023 o 21:52:37 UTC+2 burak serdar napisał(a): >>>>> >>>>>> On Sat, Jun 3, 2023 at 1:40 PM peterGo <go.pe...@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> Kamil Ziemian, >>>>>>> >>>>>>> // list of prime numbers >>>>>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>} >>>>>>> >>>>>>> The variable prime is a list of some prime numbers starting with the >>>>>>> lowest and ending with the highest prime numbers that can safely be >>>>>>> represented an int. An int may either 32 or 64 bits. >>>>>>> >>>>>>> Please explain the joke. >>>>>>> >>>>>> >>>>>> Could it be that 9 is not prime? >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Note: “Explaining a joke is like dissecting a frog. You understand >>>>>>> it better but the frog dies in the process.” >>>>>>> ― E.B. White >>>>>>> >>>>>>> peter >>>>>>> On Saturday, June 3, 2023 at 3:13:28 PM UTC-4 Kamil Ziemian wrote: >>>>>>> >>>>>>>> Is this example found in the "Composite literals" section of Go >>>>>>>> Spec a joke? >>>>>>>> // list of prime numbers >>>>>>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>} >>>>>>>> >>>>>>>> I checked on the internet and 2147483647 <(214)%20748-3647> is a >>>>>>>> prime number (https://en.wikipedia.org/wiki/2,147,483,647), so >>>>>>>> this element is fine. >>>>>>>> >>>>>>>> Best regards >>>>>>>> Kamil >>>>>>>> >>>>>>>> czwartek, 4 maja 2023 o 16:38:50 UTC+2 Kamil Ziemian napisał(a): >>>>>>>> >>>>>>>>> You convince me to your point Axel Wagner. At the same time if we >>>>>>>>> look at examples in Go Spec, I think their can be improved. >>>>>>>>> "A0, A1, and []string >>>>>>>>> A2 and struct{ a, b int } >>>>>>>>> A3 and int A4, func(int, float64) *[]string, and A5 >>>>>>>>> >>>>>>>>> B0 and C0 >>>>>>>>> D0[int, string] and E0 >>>>>>>>> []int and []int >>>>>>>>> struct{ a, b *B5 } and struct{ a, b *B5 } >>>>>>>>> func(x int, y float64) *[]string, func(int, float64) (result >>>>>>>>> *[]string), and A5" >>>>>>>>> I mean, first we need to check that A0, A1 and []string are the >>>>>>>>> same type and after few examples like D0[int, string] is the same as >>>>>>>>> E0, we >>>>>>>>> have stated []int and []int are the same type. If you convince >>>>>>>>> yourself >>>>>>>>> that A0 is the same as A1 and both are the same as []string, checking >>>>>>>>> that >>>>>>>>> []int has the same type as []int is quite trivial. I would prefer >>>>>>>>> that >>>>>>>>> examples would start from basic cases like []int is []int and []A3 is >>>>>>>>> []int >>>>>>>>> (if this one is true) and progress to more convoluted like D0[int, >>>>>>>>> string] >>>>>>>>> is E0. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Kamil >>>>>>>>> >>>>>>>>> czwartek, 4 maja 2023 o 14:12:25 UTC+2 Axel Wagner napisał(a): >>>>>>>>> >>>>>>>>>> Personally, I'd rather add more examples of "self-evidently equal >>>>>>>>>> types". In my opinion, all the type aliases in that block confuse >>>>>>>>>> matters >>>>>>>>>> quite a bit. >>>>>>>>>> >>>>>>>>>> "[]int and []int are identical" is not actually self-evident at >>>>>>>>>> all. It is self-evident that any sensible definition of type >>>>>>>>>> identity >>>>>>>>>> *should* make them identical. But it's not self-evident that the >>>>>>>>>> given >>>>>>>>>> definition *does*. Spelling that out in the example, means you are >>>>>>>>>> nudged >>>>>>>>>> to look at the definition and see how their identity follows (by >>>>>>>>>> finding >>>>>>>>>> "Two slice types are identical if they have identical element >>>>>>>>>> types"). >>>>>>>>>> >>>>>>>>>> In fact, whenever you define an equivalence relation, proving >>>>>>>>>> that it is reflexive is the very first step. And it's not always >>>>>>>>>> trivial. >>>>>>>>>> For example, `==` on `float64` is *not* reflexive. It seems obvious >>>>>>>>>> that >>>>>>>>>> NaN == NaN *should* hold from how it's spelled - but it doesn't. >>>>>>>>>> >>>>>>>>>> So, I disagree that the examples should limit themselves to cases >>>>>>>>>> where it's non-obvious that the two types should be identical. >>>>>>>>>> >>>>>>>>>> On Thu, May 4, 2023 at 12:35 PM Kamil Ziemian <kziem...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> There is a second such example just below "[]int and []int", but >>>>>>>>>>> to understand it we need some more type declarations, I listed them >>>>>>>>>>> below. >>>>>>>>>>> `type ( >>>>>>>>>>> A0 = []string >>>>>>>>>>> A1 = A0 >>>>>>>>>>> A2 = struct{ a, b int } >>>>>>>>>>> A3 = int >>>>>>>>>>> A4 = func(A3, float64) *A0 >>>>>>>>>>> A5 = func(x int, _ float64) *[]string >>>>>>>>>>> >>>>>>>>>>> B0 A0 >>>>>>>>>>> B1 []string >>>>>>>>>>> B2 struct{ a, b int } >>>>>>>>>>> B3 struct{ a, c int } >>>>>>>>>>> B4 func(int, float64) *B0 >>>>>>>>>>> B5 func(x int, y float64) *A1 >>>>>>>>>>> >>>>>>>>>>> // Unimportant part. >>>>>>>>>>> )` >>>>>>>>>>> The line in question is >>>>>>>>>>> "struct{ a, b *B5 } and struct{ a, b *B5 }" >>>>>>>>>>> which is true, but again feel out of place. I only start >>>>>>>>>>> grasping rules of types identity, but I make guess that it should >>>>>>>>>>> be >>>>>>>>>>> something like >>>>>>>>>>> "struct{ a, b *A5 } and struct{ a, b *B5 }" >>>>>>>>>>> >>>>>>>>>>> Of course it my just be that I'm just stupid. Feel free to >>>>>>>>>>> inform me that indeed I have no idea what is going on in the Go >>>>>>>>>>> Spec. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Kamil >>>>>>>>>>> czwartek, 4 maja 2023 o 12:20:35 UTC+2 Kamil Ziemian napisał(a): >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> In the section "Type identity" of Go Spec we read a list of >>>>>>>>>>>> type declarations >>>>>>>>>>>> `type ( >>>>>>>>>>>> A0 = []string >>>>>>>>>>>> A1 = A0 >>>>>>>>>>>> A2 = struct{ a, b int } >>>>>>>>>>>> A3 = int >>>>>>>>>>>> A4 = func(A3, float64) *A0 >>>>>>>>>>>> A5 = func(x int, _ float64) *[]string >>>>>>>>>>>> >>>>>>>>>>>> // Part unimportant for my point. >>>>>>>>>>>> )` >>>>>>>>>>>> and then we have list of types that are identical. Among them >>>>>>>>>>>> we can find text >>>>>>>>>>>> "[]int and []int" >>>>>>>>>>>> It is obviously true, but feel out of place. I make a humble >>>>>>>>>>>> guess that authors intended something along the lines >>>>>>>>>>>> "[]A3 and []int" >>>>>>>>>>>> Can someone look at this part of Go Spec? I feel that someone >>>>>>>>>>>> make a mistake, but at the same time humble me saying that there >>>>>>>>>>>> is any >>>>>>>>>>>> mistake in the Go Spec is something that I shouldn't do. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Kamil >>>>>>>>>>>> poniedziałek, 8 listopada 2021 o 10:59:23 UTC+1 Kamil Ziemian >>>>>>>>>>>> napisał(a): >>>>>>>>>>>> >>>>>>>>>>>>> Thank you Jan Mercl, now I start to understand this rule. >>>>>>>>>>>>> >>>>>>>>>>>>> Best >>>>>>>>>>>>> Kamil >>>>>>>>>>>>> >>>>>>>>>>>>> niedziela, 7 listopada 2021 o 19:34:41 UTC+1 Jan Mercl >>>>>>>>>>>>> napisał(a): >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sun, Nov 7, 2021 at 7:23 PM Kamil Ziemian < >>>>>>>>>>>>>> kziem...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > Can anyone give me explicit example when semicolon is >>>>>>>>>>>>>> omitted in accordance to the second rule and explanation where >>>>>>>>>>>>>> it should >>>>>>>>>>>>>> be? I probably see such situations dozens of times, I just not >>>>>>>>>>>>>> know that >>>>>>>>>>>>>> they would needed semicolon in some places. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think this is a simple example: >>>>>>>>>>>>>> https://play.golang.org/p/ZfKxTos6GjY >>>>>>>>>>>>>> >>>>>>>>>>>>>> Click "Run" to see the code is valid, then "Format" to watch >>>>>>>>>>>>>> one >>>>>>>>>>>>>> semicolon disappear and then "Run" again to see it's still >>>>>>>>>>>>>> valid code. >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>> 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...@googlegroups.com. >>>>>>>>>>> >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/001d0306-0a43-4680-a03c-3dc87e89dc5an%40googlegroups.com >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/d/msgid/golang-nuts/001d0306-0a43-4680-a03c-3dc87e89dc5an%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>>> 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...@googlegroups.com. >>>>>>> >>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/golang-nuts/22f7a3ec-fb08-498e-9e79-b1759e45b5f2n%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/golang-nuts/22f7a3ec-fb08-498e-9e79-b1759e45b5f2n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>> 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...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/65d0c91f-af15-4fbc-8d0a-0ce4a162e961n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/65d0c91f-af15-4fbc-8d0a-0ce4a162e961n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/c9e7ce74-34de-4753-80e4-7a41357cb998n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/c9e7ce74-34de-4753-80e4-7a41357cb998n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6e86577e-24cf-49f3-b98c-a47ebb2222e7n%40googlegroups.com.
