Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Patrick Smith]

Actually, this example is a bit unfortunate. Depending on the
implementation of append, the capacity of s3 may be small enough that a new
buffer must be allocated for s4, which means there is no need to test for
overlaps. https://go.dev/play/p/n5FNqlA0DaS demonstrates that this is what
happens in the current implementation, and also (x3 and x4) shows that
overlaps are handled correctly when the existing buffer has enough capacity
to be reused.

On Wed, Aug 2, 2023 at 9:49 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> You're not missing anything. The example is correct and helpful. It's also
> something that can be tested out, for definite confirmation
> .
>
>>
>> On Wednesday, 2 August 2023 at 17:59:06 UTC+1 Kamil Ziemian wrote:
>>
>>> Second, I have question about example shown in section "Appending to and
>>> copying slices".
>>>
>>> s0 := []int{0, 0}
>>> s1 := append(s0, 2)// append a single element s1 ==
>>> []int{0, 0, 2}
>>> s2 := append(s1, 3, 5, 7)  // append multiple elementss2 ==
>>> []int{0, 0, 2, 3, 5, 7}
>>> s3 := append(s2, s0...)// append a slice  s3 ==
>>> []int{0, 0, 2, 3, 5, 7, 0, 0}
>>> s4 := append(s3[3:6], s3[2:]...)   // append overlapping slices4 ==
>>> []int{3, 5, 7, 2, 3, 5, 7, 0, 0}
>>>
>>

-- 
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/CAADvV_st8xDE16ndVOCqqmwZLS1pN5U17ECM_mwjs%3DbGe61w8A%40mail.gmail.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

['Axel Wagner' via golang-nuts]

You're not missing anything. The example is correct and helpful. It's also
something that can be tested out, for definite confirmation
.

On Wed, Aug 2, 2023 at 9:57 PM Brian Candler  wrote:

> s3 == []int{0, 0, 2, 3, 5, 7, 0, 0}
>
> Therefore,
> s3[3:6] is {3, 5, 7}   // from index 3 up to but not including 6
> s3[2:] is {2, 3, 5, 7, 0, 0}  // from index 2 to end
>
> Unless I'm missing something?
>
> On Wednesday, 2 August 2023 at 17:59:06 UTC+1 Kamil Ziemian wrote:
>
>> Hello,
>>
>> First, as I probably end my first reading of Go Spec in coming days, I
>> want to thank you all for helping me in that. Thank you. :)
>>
>> Second, I have question about example shown in section "Appending to and
>> copying slices".
>>
>> s0 := []int{0, 0}
>> s1 := append(s0, 2)// append a single element s1 ==
>> []int{0, 0, 2}
>> s2 := append(s1, 3, 5, 7)  // append multiple elementss2 ==
>> []int{0, 0, 2, 3, 5, 7}
>> s3 := append(s2, s0...)// append a slice  s3 ==
>> []int{0, 0, 2, 3, 5, 7, 0, 0}
>> s4 := append(s3[3:6], s3[2:]...)   // append overlapping slices4 ==
>> []int{3, 5, 7, 2, 3, 5, 7, 0, 0}
>>
>> I didn't understand why s4 looks that after append. I would guess that if
>> I call append(s3[3:6], s3[:2]...) (s3[2:] replaced by s3[:2]) it should
>> produce result above. But I don't think clearly recently, to much on my
>> head.
>>
>> Best regards,
>> Kamil
>>
>> sobota, 29 lipca 2023 o 19:50:51 UTC+2 Kamil Ziemian napisał(a):
>>
>>> "The confusion may come from the fact that a list of forbidden built-in
>>> operations is immediately followed by a list of (mostly) allowed operations
>>> that illustrate the original rule?"
>>> You hit the nail on the head.
>>>
>>> I don't have much faith in me as programmer, so I ask about any such
>>> issue that is bothering me.
>>>
>>> Best regards,
>>> Kamil
>>>
>>> pt., 28 lip 2023 o 17:32 Brian Candler  napisał(a):
>>>
 If you wanted to be absolutely clear, you could insert "The following
 are examples of expression statements" - although it didn't really trouble
 me as-is.

 On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote:

> The confusion may come from the fact that a list of forbidden built-in
> operations is immediately followed by a list of (mostly) allowed 
> operations
> that illustrate the original rule? With the exception of "len", it may be
> more clear for it to be structure like:
> ExpressionStmt = Expression .
>
> h(x+y)
> f.Close()
> <-ch
> (<-ch)
> len("foo") // illegal if len is the built-in function
>
> The following built-in functions are not permitted in statement
> context:
> append cap complex imag len make new real
> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof
> unsafe.Slice
>
> But, that leaves the "len" example with zero context upfront.
>
> On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:
>
>> Note also, that you didn't paste the entire section:
>>
>> With the exception of specific built-in functions, function and
>> method calls and receive operations can appear in statement context. Such
>> statements may be parenthesized. […] The following built-in functions are
>> not permitted in statement context:
>>
>> This is IMO very clear about those other examples being allowed.
>>
>> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner <
>> axel.wa...@googlemail.com> wrote:
>>
>>>
>>>
>>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian 
>>> wrote:
>>>
 Hello,

 After a long break, I go back to reading Go Spec.

 In the section "Expression statements" we read that "The following
 built-in functions are not permitted in statement context:

 append cap complex imag len make new real
 unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice

 h(x+y)
 f.Close()
 <-ch
 (<-ch)
 len("foo")  // illegal if len is the built-in function"

 Are things following "h(x+y)" also forbidden in the statement
 context? This part of spec isn't specially clear in my opinion.

>>>
>>> No, they are not. Otherwise, they'd have a comment following them
>>> saying "illegal for $reason".
>>>
>>>

 Best regards,
 Kamil
 poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):

> Although the sentence is OK as it stands, the section should be
> tweaked a bit. One of the examples there (myString(0x65e5)) is valid 
> Go but
> vet rejects it, as part of the move towards disallowing this 
> conversion,
> which was there mostly for bootstrapping 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Brian Candler]

s3 == []int{0, 0, 2, 3, 5, 7, 0, 0}

Therefore,
s3[3:6] is {3, 5, 7}   // from index 3 up to but not including 6
s3[2:] is {2, 3, 5, 7, 0, 0}  // from index 2 to end

Unless I'm missing something?

On Wednesday, 2 August 2023 at 17:59:06 UTC+1 Kamil Ziemian wrote:

> Hello,
>
> First, as I probably end my first reading of Go Spec in coming days, I 
> want to thank you all for helping me in that. Thank you. :)
>
> Second, I have question about example shown in section "Appending to and 
> copying slices".
>
> s0 := []int{0, 0}
> s1 := append(s0, 2)// append a single element s1 == 
> []int{0, 0, 2}
> s2 := append(s1, 3, 5, 7)  // append multiple elementss2 == 
> []int{0, 0, 2, 3, 5, 7}
> s3 := append(s2, s0...)// append a slice  s3 == 
> []int{0, 0, 2, 3, 5, 7, 0, 0}
> s4 := append(s3[3:6], s3[2:]...)   // append overlapping slices4 == 
> []int{3, 5, 7, 2, 3, 5, 7, 0, 0}
>
> I didn't understand why s4 looks that after append. I would guess that if 
> I call append(s3[3:6], s3[:2]...) (s3[2:] replaced by s3[:2]) it should 
> produce result above. But I don't think clearly recently, to much on my 
> head.
>
> Best regards,
> Kamil
>
> sobota, 29 lipca 2023 o 19:50:51 UTC+2 Kamil Ziemian napisał(a):
>
>> "The confusion may come from the fact that a list of forbidden built-in 
>> operations is immediately followed by a list of (mostly) allowed operations 
>> that illustrate the original rule?"
>> You hit the nail on the head.
>>
>> I don't have much faith in me as programmer, so I ask about any such 
>> issue that is bothering me.
>>
>> Best regards,
>> Kamil
>>
>> pt., 28 lip 2023 o 17:32 Brian Candler  napisał(a):
>>
>>> If you wanted to be absolutely clear, you could insert "The following 
>>> are examples of expression statements" - although it didn't really trouble 
>>> me as-is.
>>>
>>> On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote:
>>>
 The confusion may come from the fact that a list of forbidden built-in 
 operations is immediately followed by a list of (mostly) allowed 
 operations 
 that illustrate the original rule? With the exception of "len", it may be 
 more clear for it to be structure like:
 ExpressionStmt = Expression .

 h(x+y)
 f.Close()
 <-ch
 (<-ch)
 len("foo") // illegal if len is the built-in function

 The following built-in functions are not permitted in statement 
 context:
 append cap complex imag len make new real
 unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof 
 unsafe.Slice

 But, that leaves the "len" example with zero context upfront.

 On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:

> Note also, that you didn't paste the entire section:
>
> With the exception of specific built-in functions, function and method 
> calls and receive operations can appear in statement context. Such 
> statements may be parenthesized. […] The following built-in functions are 
> not permitted in statement context:
>
> This is IMO very clear about those other examples being allowed.
>
> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner  
> wrote:
>
>>
>>
>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian  
>> wrote:
>>
>>> Hello,
>>>
>>> After a long break, I go back to reading Go Spec.
>>>
>>> In the section "Expression statements" we read that "The following 
>>> built-in functions are not permitted in statement context:
>>>
>>> append cap complex imag len make new real
>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
>>>
>>> h(x+y)
>>> f.Close()
>>> <-ch
>>> (<-ch)
>>> len("foo")  // illegal if len is the built-in function"
>>>
>>> Are things following "h(x+y)" also forbidden in the statement 
>>> context? This part of spec isn't specially clear in my opinion.
>>>
>>
>> No, they are not. Otherwise, they'd have a comment following them 
>> saying "illegal for $reason".
>>  
>>
>>>
>>> Best regards,
>>> Kamil
>>> poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):
>>>
 Although the sentence is OK as it stands, the section should be 
 tweaked a bit. One of the examples there (myString(0x65e5)) is valid 
 Go but 
 vet rejects it, as part of the move towards disallowing this 
 conversion, 
 which was there mostly for bootstrapping the libraries.

 -rob


 On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
 golan...@googlegroups.com> wrote:

> Ah, the spec does actually say:
>>
>> Converting a signed or unsigned integer value to a string type 
>> yields a string containing the UTF-8 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Hello,

First, as I probably end my first reading of Go Spec in coming days, I want 
to thank you all for helping me in that. Thank you. :)

Second, I have question about example shown in section "Appending to and 
copying slices".

s0 := []int{0, 0}
s1 := append(s0, 2)// append a single element s1 == 
[]int{0, 0, 2}
s2 := append(s1, 3, 5, 7)  // append multiple elementss2 == 
[]int{0, 0, 2, 3, 5, 7}
s3 := append(s2, s0...)// append a slice  s3 == 
[]int{0, 0, 2, 3, 5, 7, 0, 0}
s4 := append(s3[3:6], s3[2:]...)   // append overlapping slices4 == 
[]int{3, 5, 7, 2, 3, 5, 7, 0, 0}

I didn't understand why s4 looks that after append. I would guess that if I 
call append(s3[3:6], s3[:2]...) (s3[2:] replaced by s3[:2]) it should 
produce result above. But I don't think clearly recently, to much on my 
head.

Best regards,
Kamil

sobota, 29 lipca 2023 o 19:50:51 UTC+2 Kamil Ziemian napisał(a):

> "The confusion may come from the fact that a list of forbidden built-in 
> operations is immediately followed by a list of (mostly) allowed operations 
> that illustrate the original rule?"
> You hit the nail on the head.
>
> I don't have much faith in me as programmer, so I ask about any such issue 
> that is bothering me.
>
> Best regards,
> Kamil
>
> pt., 28 lip 2023 o 17:32 Brian Candler  napisał(a):
>
>> If you wanted to be absolutely clear, you could insert "The following are 
>> examples of expression statements" - although it didn't really trouble me 
>> as-is.
>>
>> On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote:
>>
>>> The confusion may come from the fact that a list of forbidden built-in 
>>> operations is immediately followed by a list of (mostly) allowed operations 
>>> that illustrate the original rule? With the exception of "len", it may be 
>>> more clear for it to be structure like:
>>> ExpressionStmt = Expression .
>>>
>>> h(x+y)
>>> f.Close()
>>> <-ch
>>> (<-ch)
>>> len("foo") // illegal if len is the built-in function
>>>
>>> The following built-in functions are not permitted in statement 
>>> context:
>>> append cap complex imag len make new real
>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof 
>>> unsafe.Slice
>>>
>>> But, that leaves the "len" example with zero context upfront.
>>>
>>> On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:
>>>
 Note also, that you didn't paste the entire section:

 With the exception of specific built-in functions, function and method 
 calls and receive operations can appear in statement context. Such 
 statements may be parenthesized. […] The following built-in functions are 
 not permitted in statement context:

 This is IMO very clear about those other examples being allowed.

 On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner  
 wrote:

>
>
> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian  
> wrote:
>
>> Hello,
>>
>> After a long break, I go back to reading Go Spec.
>>
>> In the section "Expression statements" we read that "The following 
>> built-in functions are not permitted in statement context:
>>
>> append cap complex imag len make new real
>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
>>
>> h(x+y)
>> f.Close()
>> <-ch
>> (<-ch)
>> len("foo")  // illegal if len is the built-in function"
>>
>> Are things following "h(x+y)" also forbidden in the statement 
>> context? This part of spec isn't specially clear in my opinion.
>>
>
> No, they are not. Otherwise, they'd have a comment following them 
> saying "illegal for $reason".
>  
>
>>
>> Best regards,
>> Kamil
>> poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):
>>
>>> Although the sentence is OK as it stands, the section should be 
>>> tweaked a bit. One of the examples there (myString(0x65e5)) is valid Go 
>>> but 
>>> vet rejects it, as part of the move towards disallowing this 
>>> conversion, 
>>> which was there mostly for bootstrapping the libraries.
>>>
>>> -rob
>>>
>>>
>>> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
 Ah, the spec does actually say:
>
> Converting a signed or unsigned integer value to a string type 
> yields a string containing the UTF-8 representation of the integer. 
> Values 
> outside the range of valid Unicode code points are converted to 
> "\uFFFD".


 Personally, I think this is fine as is. I think people understand 
 what happens from these two sentences. 

 On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner <
 axel.wa...@googlemail.com> wrote:

> I'm not 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

"The confusion may come from the fact that a list of forbidden built-in
operations is immediately followed by a list of (mostly) allowed operations
that illustrate the original rule?"
You hit the nail on the head.

I don't have much faith in me as programmer, so I ask about any such issue
that is bothering me.

Best regards,
Kamil

pt., 28 lip 2023 o 17:32 Brian Candler  napisał(a):

> If you wanted to be absolutely clear, you could insert "The following are
> examples of expression statements" - although it didn't really trouble me
> as-is.
>
> On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote:
>
>> The confusion may come from the fact that a list of forbidden built-in
>> operations is immediately followed by a list of (mostly) allowed operations
>> that illustrate the original rule? With the exception of "len", it may be
>> more clear for it to be structure like:
>> ExpressionStmt = Expression .
>>
>> h(x+y)
>> f.Close()
>> <-ch
>> (<-ch)
>> len("foo") // illegal if len is the built-in function
>>
>> The following built-in functions are not permitted in statement
>> context:
>> append cap complex imag len make new real
>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof
>> unsafe.Slice
>>
>> But, that leaves the "len" example with zero context upfront.
>>
>> On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:
>>
>>> Note also, that you didn't paste the entire section:
>>>
>>> With the exception of specific built-in functions, function and method
>>> calls and receive operations can appear in statement context. Such
>>> statements may be parenthesized. […] The following built-in functions are
>>> not permitted in statement context:
>>>
>>> This is IMO very clear about those other examples being allowed.
>>>
>>> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner 
>>> wrote:
>>>


 On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian 
 wrote:

> Hello,
>
> After a long break, I go back to reading Go Spec.
>
> In the section "Expression statements" we read that "The following
> built-in functions are not permitted in statement context:
>
> append cap complex imag len make new real
> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
>
> h(x+y)
> f.Close()
> <-ch
> (<-ch)
> len("foo")  // illegal if len is the built-in function"
>
> Are things following "h(x+y)" also forbidden in the statement context?
> This part of spec isn't specially clear in my opinion.
>

 No, they are not. Otherwise, they'd have a comment following them
 saying "illegal for $reason".


>
> Best regards,
> Kamil
> poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):
>
>> Although the sentence is OK as it stands, the section should be
>> tweaked a bit. One of the examples there (myString(0x65e5)) is valid Go 
>> but
>> vet rejects it, as part of the move towards disallowing this conversion,
>> which was there mostly for bootstrapping the libraries.
>>
>> -rob
>>
>>
>> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> Ah, the spec does actually say:

 Converting a signed or unsigned integer value to a string type
 yields a string containing the UTF-8 representation of the integer. 
 Values
 outside the range of valid Unicode code points are converted to 
 "\uFFFD".
>>>
>>>
>>> Personally, I think this is fine as is. I think people understand
>>> what happens from these two sentences.
>>>
>>> On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner <
>>> axel.wa...@googlemail.com> wrote:
>>>
 I'm not entirely sure. I don't think your phrasing is correct, as
 it doesn't represent what happens if the integer value exceeds the 
 range of
 valid codepoints (i.e. if it needs more than 32 bits to represent). 
 That
 being said, the sentence as is also isn't really precise about it. From
 what I can tell, the result is not valid UTF-8 in any case.

 I think it might make sense to file an issue about this, though in
 general that conversion is deprecated anyway and gets flagged by `go 
 vet`
 (and `go test`) because it is not what's usually expected. So I'm not 
 sure
 how important it is to get this exactly right and understandable.


 On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian 
 wrote:

> I have some hair splitting question. In the "Conversions to and
> from a string type" we read:
> "Converting a signed or unsigned integer value to a string type
> yields a string containing the UTF-8 representation of the integer."
>
> 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Brian Candler]

If you wanted to be absolutely clear, you could insert "The following are 
examples of expression statements" - although it didn't really trouble me 
as-is.

On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote:

> The confusion may come from the fact that a list of forbidden built-in 
> operations is immediately followed by a list of (mostly) allowed operations 
> that illustrate the original rule? With the exception of "len", it may be 
> more clear for it to be structure like:
> ExpressionStmt = Expression .
>
> h(x+y)
> f.Close()
> <-ch
> (<-ch)
> len("foo") // illegal if len is the built-in function
>
> The following built-in functions are not permitted in statement 
> context:
> append cap complex imag len make new real
> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof 
> unsafe.Slice
>
> But, that leaves the "len" example with zero context upfront.
>
> On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:
>
>> Note also, that you didn't paste the entire section:
>>
>> With the exception of specific built-in functions, function and method 
>> calls and receive operations can appear in statement context. Such 
>> statements may be parenthesized. […] The following built-in functions are 
>> not permitted in statement context:
>>
>> This is IMO very clear about those other examples being allowed.
>>
>> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner  
>> wrote:
>>
>>>
>>>
>>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian  
>>> wrote:
>>>
 Hello,

 After a long break, I go back to reading Go Spec.

 In the section "Expression statements" we read that "The following 
 built-in functions are not permitted in statement context:

 append cap complex imag len make new real
 unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice

 h(x+y)
 f.Close()
 <-ch
 (<-ch)
 len("foo")  // illegal if len is the built-in function"

 Are things following "h(x+y)" also forbidden in the statement context? 
 This part of spec isn't specially clear in my opinion.

>>>
>>> No, they are not. Otherwise, they'd have a comment following them saying 
>>> "illegal for $reason".
>>>  
>>>

 Best regards,
 Kamil
 poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):

> Although the sentence is OK as it stands, the section should be 
> tweaked a bit. One of the examples there (myString(0x65e5)) is valid Go 
> but 
> vet rejects it, as part of the move towards disallowing this conversion, 
> which was there mostly for bootstrapping the libraries.
>
> -rob
>
>
> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Ah, the spec does actually say:
>>>
>>> Converting a signed or unsigned integer value to a string type 
>>> yields a string containing the UTF-8 representation of the integer. 
>>> Values 
>>> outside the range of valid Unicode code points are converted to 
>>> "\uFFFD".
>>
>>
>> Personally, I think this is fine as is. I think people understand 
>> what happens from these two sentences. 
>>
>> On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner <
>> axel.wa...@googlemail.com> wrote:
>>
>>> I'm not entirely sure. I don't think your phrasing is correct, as it 
>>> doesn't represent what happens if the integer value exceeds the range 
>>> of 
>>> valid codepoints (i.e. if it needs more than 32 bits to represent). 
>>> That 
>>> being said, the sentence as is also isn't really precise about it. From 
>>> what I can tell, the result is not valid UTF-8 in any case.
>>>
>>> I think it might make sense to file an issue about this, though in 
>>> general that conversion is deprecated anyway and gets flagged by `go 
>>> vet` 
>>> (and `go test`) because it is not what's usually expected. So I'm not 
>>> sure 
>>> how important it is to get this exactly right and understandable.
>>>
>>>
>>> On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian  
>>> wrote:
>>>
 I have some hair splitting question. In the "Conversions to and 
 from a string type" we read:
 "Converting a signed or unsigned integer value to a string type 
 yields a string containing the UTF-8 representation of the integer."

 Would it be more corrected to say, that conversion from integer to 
 string gives you UTF-8 representation of code point described by value 
 of 
 the integer? Or maybe it is indeed representation of integer described 
 by 
 UTF-8 specification?

 Best regards,
 Kamil
 czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian 
 napisał(a):

> Hello,
>
> From what I 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Jason Phillips]

The confusion may come from the fact that a list of forbidden built-in 
operations is immediately followed by a list of (mostly) allowed operations 
that illustrate the original rule? With the exception of "len", it may be 
more clear for it to be structure like:
ExpressionStmt = Expression .

h(x+y)
f.Close()
<-ch
(<-ch)
len("foo") // illegal if len is the built-in function

The following built-in functions are not permitted in statement context:
append cap complex imag len make new real
unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice

But, that leaves the "len" example with zero context upfront.

On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:

> Note also, that you didn't paste the entire section:
>
> With the exception of specific built-in functions, function and method 
> calls and receive operations can appear in statement context. Such 
> statements may be parenthesized. […] The following built-in functions are 
> not permitted in statement context:
>
> This is IMO very clear about those other examples being allowed.
>
> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner  
> wrote:
>
>>
>>
>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian  wrote:
>>
>>> Hello,
>>>
>>> After a long break, I go back to reading Go Spec.
>>>
>>> In the section "Expression statements" we read that "The following 
>>> built-in functions are not permitted in statement context:
>>>
>>> append cap complex imag len make new real
>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
>>>
>>> h(x+y)
>>> f.Close()
>>> <-ch
>>> (<-ch)
>>> len("foo")  // illegal if len is the built-in function"
>>>
>>> Are things following "h(x+y)" also forbidden in the statement context? 
>>> This part of spec isn't specially clear in my opinion.
>>>
>>
>> No, they are not. Otherwise, they'd have a comment following them saying 
>> "illegal for $reason".
>>  
>>
>>>
>>> Best regards,
>>> Kamil
>>> poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):
>>>
 Although the sentence is OK as it stands, the section should be tweaked 
 a bit. One of the examples there (myString(0x65e5)) is valid Go but vet 
 rejects it, as part of the move towards disallowing this conversion, which 
 was there mostly for bootstrapping the libraries.

 -rob


 On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
 golan...@googlegroups.com> wrote:

> Ah, the spec does actually say:
>>
>> Converting a signed or unsigned integer value to a string type yields 
>> a string containing the UTF-8 representation of the integer. Values 
>> outside 
>> the range of valid Unicode code points are converted to "\uFFFD".
>
>
> Personally, I think this is fine as is. I think people understand what 
> happens from these two sentences. 
>
> On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner  
> wrote:
>
>> I'm not entirely sure. I don't think your phrasing is correct, as it 
>> doesn't represent what happens if the integer value exceeds the range of 
>> valid codepoints (i.e. if it needs more than 32 bits to represent). That 
>> being said, the sentence as is also isn't really precise about it. From 
>> what I can tell, the result is not valid UTF-8 in any case.
>>
>> I think it might make sense to file an issue about this, though in 
>> general that conversion is deprecated anyway and gets flagged by `go 
>> vet` 
>> (and `go test`) because it is not what's usually expected. So I'm not 
>> sure 
>> how important it is to get this exactly right and understandable.
>>
>>
>> On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian  
>> wrote:
>>
>>> I have some hair splitting question. In the "Conversions to and from 
>>> a string type" we read:
>>> "Converting a signed or unsigned integer value to a string type 
>>> yields a string containing the UTF-8 representation of the integer."
>>>
>>> Would it be more corrected to say, that conversion from integer to 
>>> string gives you UTF-8 representation of code point described by value 
>>> of 
>>> the integer? Or maybe it is indeed representation of integer described 
>>> by 
>>> UTF-8 specification?
>>>
>>> Best regards,
>>> Kamil
>>> czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian 
>>> napisał(a):
>>>
 Hello,

 From what I understand proper Gopher read at least one time "The Go 
 Programming Language Specification" (https://golang.org/ref/spec) 
 and now I need to read it too.

 I learn something of Extended Backus-Naur Form to understand it, so 
 if I say something stupid beyond belief, I hope you will forgive me. 
 In the 
 first part "Notation" (https://golang.org/ref/spec#Notation) I 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

['Axel Wagner' via golang-nuts]

Note also, that you didn't paste the entire section:

With the exception of specific built-in functions, function and method
calls and receive operations can appear in statement context. Such
statements may be parenthesized. […] The following built-in functions are
not permitted in statement context:

This is IMO very clear about those other examples being allowed.

On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner 
wrote:

>
>
> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian 
> wrote:
>
>> Hello,
>>
>> After a long break, I go back to reading Go Spec.
>>
>> In the section "Expression statements" we read that "The following
>> built-in functions are not permitted in statement context:
>>
>> append cap complex imag len make new real
>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
>>
>> h(x+y)
>> f.Close()
>> <-ch
>> (<-ch)
>> len("foo")  // illegal if len is the built-in function"
>>
>> Are things following "h(x+y)" also forbidden in the statement context?
>> This part of spec isn't specially clear in my opinion.
>>
>
> No, they are not. Otherwise, they'd have a comment following them saying
> "illegal for $reason".
>
>
>>
>> Best regards,
>> Kamil
>> poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):
>>
>>> Although the sentence is OK as it stands, the section should be tweaked
>>> a bit. One of the examples there (myString(0x65e5)) is valid Go but vet
>>> rejects it, as part of the move towards disallowing this conversion, which
>>> was there mostly for bootstrapping the libraries.
>>>
>>> -rob
>>>
>>>
>>> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
 Ah, the spec does actually say:
>
> Converting a signed or unsigned integer value to a string type yields
> a string containing the UTF-8 representation of the integer. Values 
> outside
> the range of valid Unicode code points are converted to "\uFFFD".


 Personally, I think this is fine as is. I think people understand what
 happens from these two sentences.

 On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner 
 wrote:

> I'm not entirely sure. I don't think your phrasing is correct, as it
> doesn't represent what happens if the integer value exceeds the range of
> valid codepoints (i.e. if it needs more than 32 bits to represent). That
> being said, the sentence as is also isn't really precise about it. From
> what I can tell, the result is not valid UTF-8 in any case.
>
> I think it might make sense to file an issue about this, though in
> general that conversion is deprecated anyway and gets flagged by `go vet`
> (and `go test`) because it is not what's usually expected. So I'm not sure
> how important it is to get this exactly right and understandable.
>
>
> On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian 
> wrote:
>
>> I have some hair splitting question. In the "Conversions to and from
>> a string type" we read:
>> "Converting a signed or unsigned integer value to a string type
>> yields a string containing the UTF-8 representation of the integer."
>>
>> Would it be more corrected to say, that conversion from integer to
>> string gives you UTF-8 representation of code point described by value of
>> the integer? Or maybe it is indeed representation of integer described by
>> UTF-8 specification?
>>
>> Best regards,
>> Kamil
>> czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian
>> napisał(a):
>>
>>> Hello,
>>>
>>> From what I understand proper Gopher read at least one time "The Go
>>> Programming Language Specification" (https://golang.org/ref/spec)
>>> and now I need to read it too.
>>>
>>> I learn something of Extended Backus-Naur Form to understand it, so
>>> if I say something stupid beyond belief, I hope you will forgive me. In 
>>> the
>>> first part "Notation" (https://golang.org/ref/spec#Notation) I
>>> believe that I understand meaning of all concepts except of
>>> "production_name". On one hand "production_name" means that it is name 
>>> of
>>> the production, not rocket science here. On the other, after reading 
>>> about
>>> EBNF I feel that I should have more information about it. Can you 
>>> explain
>>> it to me?
>>>
>>> Again I'm new to EBNF, so maybe this is stupid question.
>>>
>>> Best
>>> Kamil
>>>
>>> --
>> 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/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com
>> 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

['Axel Wagner' via golang-nuts]

On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian  wrote:

> Hello,
>
> After a long break, I go back to reading Go Spec.
>
> In the section "Expression statements" we read that "The following
> built-in functions are not permitted in statement context:
>
> append cap complex imag len make new real
> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
>
> h(x+y)
> f.Close()
> <-ch
> (<-ch)
> len("foo")  // illegal if len is the built-in function"
>
> Are things following "h(x+y)" also forbidden in the statement context?
> This part of spec isn't specially clear in my opinion.
>

No, they are not. Otherwise, they'd have a comment following them saying
"illegal for $reason".


>
> Best regards,
> Kamil
> poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):
>
>> Although the sentence is OK as it stands, the section should be tweaked a
>> bit. One of the examples there (myString(0x65e5)) is valid Go but vet
>> rejects it, as part of the move towards disallowing this conversion, which
>> was there mostly for bootstrapping the libraries.
>>
>> -rob
>>
>>
>> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> Ah, the spec does actually say:

 Converting a signed or unsigned integer value to a string type yields a
 string containing the UTF-8 representation of the integer. Values outside
 the range of valid Unicode code points are converted to "\uFFFD".
>>>
>>>
>>> Personally, I think this is fine as is. I think people understand what
>>> happens from these two sentences.
>>>
>>> On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner 
>>> wrote:
>>>
 I'm not entirely sure. I don't think your phrasing is correct, as it
 doesn't represent what happens if the integer value exceeds the range of
 valid codepoints (i.e. if it needs more than 32 bits to represent). That
 being said, the sentence as is also isn't really precise about it. From
 what I can tell, the result is not valid UTF-8 in any case.

 I think it might make sense to file an issue about this, though in
 general that conversion is deprecated anyway and gets flagged by `go vet`
 (and `go test`) because it is not what's usually expected. So I'm not sure
 how important it is to get this exactly right and understandable.


 On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian 
 wrote:

> I have some hair splitting question. In the "Conversions to and from a
> string type" we read:
> "Converting a signed or unsigned integer value to a string type yields
> a string containing the UTF-8 representation of the integer."
>
> Would it be more corrected to say, that conversion from integer to
> string gives you UTF-8 representation of code point described by value of
> the integer? Or maybe it is indeed representation of integer described by
> UTF-8 specification?
>
> Best regards,
> Kamil
> czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian
> napisał(a):
>
>> Hello,
>>
>> From what I understand proper Gopher read at least one time "The Go
>> Programming Language Specification" (https://golang.org/ref/spec)
>> and now I need to read it too.
>>
>> I learn something of Extended Backus-Naur Form to understand it, so
>> if I say something stupid beyond belief, I hope you will forgive me. In 
>> the
>> first part "Notation" (https://golang.org/ref/spec#Notation) I
>> believe that I understand meaning of all concepts except of
>> "production_name". On one hand "production_name" means that it is name of
>> the production, not rocket science here. On the other, after reading 
>> about
>> EBNF I feel that I should have more information about it. Can you explain
>> it to me?
>>
>> Again I'm new to EBNF, so maybe this is stupid question.
>>
>> Best
>> Kamil
>>
>> --
> 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/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com
> 
> .
>
 --
>>> 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/CAEkBMfHaG8bYNLvLERu0-ad57wpoWsiB%2BFC5asyKA7FH6%2BvgZw%40mail.gmail.com
>>> 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Hello,

After a long break, I go back to reading Go Spec.

In the section "Expression statements" we read that "The following built-in 
functions are not permitted in statement context:

append cap complex imag len make new real
unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice

h(x+y)
f.Close()
<-ch
(<-ch)
len("foo")  // illegal if len is the built-in function"

Are things following "h(x+y)" also forbidden in the statement context? This 
part of spec isn't specially clear in my opinion.

Best regards,
Kamil
poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):

> Although the sentence is OK as it stands, the section should be tweaked a 
> bit. One of the examples there (myString(0x65e5)) is valid Go but vet 
> rejects it, as part of the move towards disallowing this conversion, which 
> was there mostly for bootstrapping the libraries.
>
> -rob
>
>
> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Ah, the spec does actually say:
>>>
>>> Converting a signed or unsigned integer value to a string type yields a 
>>> string containing the UTF-8 representation of the integer. Values outside 
>>> the range of valid Unicode code points are converted to "\uFFFD".
>>
>>
>> Personally, I think this is fine as is. I think people understand what 
>> happens from these two sentences. 
>>
>> On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner  
>> wrote:
>>
>>> I'm not entirely sure. I don't think your phrasing is correct, as it 
>>> doesn't represent what happens if the integer value exceeds the range of 
>>> valid codepoints (i.e. if it needs more than 32 bits to represent). That 
>>> being said, the sentence as is also isn't really precise about it. From 
>>> what I can tell, the result is not valid UTF-8 in any case.
>>>
>>> I think it might make sense to file an issue about this, though in 
>>> general that conversion is deprecated anyway and gets flagged by `go vet` 
>>> (and `go test`) because it is not what's usually expected. So I'm not sure 
>>> how important it is to get this exactly right and understandable.
>>>
>>>
>>> On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian  
>>> wrote:
>>>
 I have some hair splitting question. In the "Conversions to and from a 
 string type" we read:
 "Converting a signed or unsigned integer value to a string type yields 
 a string containing the UTF-8 representation of the integer."

 Would it be more corrected to say, that conversion from integer to 
 string gives you UTF-8 representation of code point described by value of 
 the integer? Or maybe it is indeed representation of integer described by 
 UTF-8 specification?

 Best regards,
 Kamil
 czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian 
 napisał(a):

> Hello,
>
> From what I understand proper Gopher read at least one time "The Go 
> Programming Language Specification" (https://golang.org/ref/spec) and 
> now I need to read it too.
>
> I learn something of Extended Backus-Naur Form to understand it, so if 
> I say something stupid beyond belief, I hope you will forgive me. In the 
> first part "Notation" (https://golang.org/ref/spec#Notation) I 
> believe that I understand meaning of all concepts except of 
> "production_name". On one hand "production_name" means that it is name of 
> the production, not rocket science here. On the other, after reading 
> about 
> EBNF I feel that I should have more information about it. Can you explain 
> it to me?
>
> Again I'm new to EBNF, so maybe this is stupid question.
>
> Best
> Kamil
>
> -- 
 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/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com
  
 
 .

>>> -- 
>> 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/CAEkBMfHaG8bYNLvLERu0-ad57wpoWsiB%2BFC5asyKA7FH6%2BvgZw%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Rob Pike]

Although the sentence is OK as it stands, the section should be tweaked a
bit. One of the examples there (myString(0x65e5)) is valid Go but vet
rejects it, as part of the move towards disallowing this conversion, which
was there mostly for bootstrapping the libraries.

-rob


On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Ah, the spec does actually say:
>>
>> Converting a signed or unsigned integer value to a string type yields a
>> string containing the UTF-8 representation of the integer. Values outside
>> the range of valid Unicode code points are converted to "\uFFFD".
>
>
> Personally, I think this is fine as is. I think people understand what
> happens from these two sentences.
>
> On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner 
> wrote:
>
>> I'm not entirely sure. I don't think your phrasing is correct, as it
>> doesn't represent what happens if the integer value exceeds the range of
>> valid codepoints (i.e. if it needs more than 32 bits to represent). That
>> being said, the sentence as is also isn't really precise about it. From
>> what I can tell, the result is not valid UTF-8 in any case.
>>
>> I think it might make sense to file an issue about this, though in
>> general that conversion is deprecated anyway and gets flagged by `go vet`
>> (and `go test`) because it is not what's usually expected. So I'm not sure
>> how important it is to get this exactly right and understandable.
>>
>>
>> On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian 
>> wrote:
>>
>>> I have some hair splitting question. In the "Conversions to and from a
>>> string type" we read:
>>> "Converting a signed or unsigned integer value to a string type yields a
>>> string containing the UTF-8 representation of the integer."
>>>
>>> Would it be more corrected to say, that conversion from integer to
>>> string gives you UTF-8 representation of code point described by value of
>>> the integer? Or maybe it is indeed representation of integer described by
>>> UTF-8 specification?
>>>
>>> Best regards,
>>> Kamil
>>> czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian napisał(a):
>>>
 Hello,

 From what I understand proper Gopher read at least one time "The Go
 Programming Language Specification" (https://golang.org/ref/spec) and
 now I need to read it too.

 I learn something of Extended Backus-Naur Form to understand it, so if
 I say something stupid beyond belief, I hope you will forgive me. In the
 first part "Notation" (https://golang.org/ref/spec#Notation) I believe
 that I understand meaning of all concepts except of "production_name". On
 one hand "production_name" means that it is name of the production, not
 rocket science here. On the other, after reading about EBNF I feel that I
 should have more information about it. Can you explain it to me?

 Again I'm new to EBNF, so maybe this is stupid question.

 Best
 Kamil

 --
>>> 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/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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/CAEkBMfHaG8bYNLvLERu0-ad57wpoWsiB%2BFC5asyKA7FH6%2BvgZw%40mail.gmail.com
> 
> .
>

-- 
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/CAOXNBZQ3cNot51jFKA%2B--PGO%2B06p5xdTr%2BVWum20Twz4y3ed6g%40mail.gmail.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

['Axel Wagner' via golang-nuts]

Ah, the spec does actually say:
>
> Converting a signed or unsigned integer value to a string type yields a
> string containing the UTF-8 representation of the integer. Values outside
> the range of valid Unicode code points are converted to "\uFFFD".


Personally, I think this is fine as is. I think people understand what
happens from these two sentences.

On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner 
wrote:

> I'm not entirely sure. I don't think your phrasing is correct, as it
> doesn't represent what happens if the integer value exceeds the range of
> valid codepoints (i.e. if it needs more than 32 bits to represent). That
> being said, the sentence as is also isn't really precise about it. From
> what I can tell, the result is not valid UTF-8 in any case.
>
> I think it might make sense to file an issue about this, though in general
> that conversion is deprecated anyway and gets flagged by `go vet` (and `go
> test`) because it is not what's usually expected. So I'm not sure how
> important it is to get this exactly right and understandable.
>
>
> On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian 
> wrote:
>
>> I have some hair splitting question. In the "Conversions to and from a
>> string type" we read:
>> "Converting a signed or unsigned integer value to a string type yields a
>> string containing the UTF-8 representation of the integer."
>>
>> Would it be more corrected to say, that conversion from integer to string
>> gives you UTF-8 representation of code point described by value of the
>> integer? Or maybe it is indeed representation of integer described by UTF-8
>> specification?
>>
>> Best regards,
>> Kamil
>> czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian napisał(a):
>>
>>> Hello,
>>>
>>> From what I understand proper Gopher read at least one time "The Go
>>> Programming Language Specification" (https://golang.org/ref/spec) and
>>> now I need to read it too.
>>>
>>> I learn something of Extended Backus-Naur Form to understand it, so if I
>>> say something stupid beyond belief, I hope you will forgive me. In the
>>> first part "Notation" (https://golang.org/ref/spec#Notation) I believe
>>> that I understand meaning of all concepts except of "production_name". On
>>> one hand "production_name" means that it is name of the production, not
>>> rocket science here. On the other, after reading about EBNF I feel that I
>>> should have more information about it. Can you explain it to me?
>>>
>>> Again I'm new to EBNF, so maybe this is stupid question.
>>>
>>> Best
>>> Kamil
>>>
>>> --
>> 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/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CAEkBMfHaG8bYNLvLERu0-ad57wpoWsiB%2BFC5asyKA7FH6%2BvgZw%40mail.gmail.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

['Axel Wagner' via golang-nuts]

I'm not entirely sure. I don't think your phrasing is correct, as it
doesn't represent what happens if the integer value exceeds the range of
valid codepoints (i.e. if it needs more than 32 bits to represent). That
being said, the sentence as is also isn't really precise about it. From
what I can tell, the result is not valid UTF-8 in any case.

I think it might make sense to file an issue about this, though in general
that conversion is deprecated anyway and gets flagged by `go vet` (and `go
test`) because it is not what's usually expected. So I'm not sure how
important it is to get this exactly right and understandable.


On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian  wrote:

> I have some hair splitting question. In the "Conversions to and from a
> string type" we read:
> "Converting a signed or unsigned integer value to a string type yields a
> string containing the UTF-8 representation of the integer."
>
> Would it be more corrected to say, that conversion from integer to string
> gives you UTF-8 representation of code point described by value of the
> integer? Or maybe it is indeed representation of integer described by UTF-8
> specification?
>
> Best regards,
> Kamil
> czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian napisał(a):
>
>> Hello,
>>
>> From what I understand proper Gopher read at least one time "The Go
>> Programming Language Specification" (https://golang.org/ref/spec) and
>> now I need to read it too.
>>
>> I learn something of Extended Backus-Naur Form to understand it, so if I
>> say something stupid beyond belief, I hope you will forgive me. In the
>> first part "Notation" (https://golang.org/ref/spec#Notation) I believe
>> that I understand meaning of all concepts except of "production_name". On
>> one hand "production_name" means that it is name of the production, not
>> rocket science here. On the other, after reading about EBNF I feel that I
>> should have more information about it. Can you explain it to me?
>>
>> Again I'm new to EBNF, so maybe this is stupid question.
>>
>> Best
>> Kamil
>>
>> --
> 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/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfGE9rLy_DTSwq1rwFzUUSWHXeKa9qLvCeUzP72ihuVDzw%40mail.gmail.com.

[go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

I have some hair splitting question. In the "Conversions to and from a 
string type" we read:
"Converting a signed or unsigned integer value to a string type yields a 
string containing the UTF-8 representation of the integer."

Would it be more corrected to say, that conversion from integer to string 
gives you UTF-8 representation of code point described by value of the 
integer? Or maybe it is indeed representation of integer described by UTF-8 
specification?

Best regards,
Kamil
czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian napisał(a):

> Hello,
>
> From what I understand proper Gopher read at least one time "The Go 
> Programming Language Specification" (https://golang.org/ref/spec) and now 
> I need to read it too.
>
> I learn something of Extended Backus-Naur Form to understand it, so if I 
> say something stupid beyond belief, I hope you will forgive me. In the 
> first part "Notation" (https://golang.org/ref/spec#Notation) I believe 
> that I understand meaning of all concepts except of "production_name". On 
> one hand "production_name" means that it is name of the production, not 
> rocket science here. On the other, after reading about EBNF I feel that I 
> should have more information about it. Can you explain it to me?
>
> Again I'm new to EBNF, so maybe this is stupid question.
>
> Best
> Kamil
>
>

-- 
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/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

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  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  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  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 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

['Axel Wagner' via golang-nuts]

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  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  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  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, 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

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  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  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 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

['Sean Liao' via golang-nuts]

It is not a typo

https://go.dev/issue/24451

- sean


On Sat, Jun 3, 2023 at 10:05 PM peterGo  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  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 
>>> 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 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[peterGo]

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  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  
>> 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 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

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  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  
> 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
>>> 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[burak serdar]

On Sat, Jun 3, 2023 at 1:40 PM peterGo  wrote:

>
> Kamil Ziemian,
>
> // list of prime numbers
> primes := []int{2, 3, 5, 7, 9, 2147483647}
>
> 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 
 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"
>> 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[peterGo]

Kamil Ziemian,

// list of prime numbers 
primes := []int{2, 3, 5, 7, 9, 2147483647}

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. 

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  
>>> 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 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

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}

I checked on the internet and 2147483647 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  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  
>> 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. 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

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  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  
> 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 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

['Axel Wagner' via golang-nuts]

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  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 
 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+unsubscr...@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
> 
> .
>

-- 
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/CAEkBMfH7kXPiZ9bH_82fGw1DxRapBBABbNvWgVp-AaFUznLrpA%40mail.gmail.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

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  
>>> 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+unsubscr...@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.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

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  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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/83a97c7c-9a79-41ff-a02d-6a1812db4059n%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

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  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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6ee00e8b-c928-46af-8f2b-e99f4bfcbb20n%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Jan Mercl]

On Sun, Nov 7, 2021 at 7:23 PM Kamil Ziemian  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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UoYGfj34k8XH%2Bq3q%2BCjpwuTAMMZyAN-Bp0ucuU20fRAQ%40mail.gmail.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Hello,

I go back to reading Go spec and I read about omitting semicolon in Go 
code. I know from some Rob Pike talks on YT or similar source, that 
compiler inserts semicolon in "places where C programmer would expected it 
to write". And since I try to follow Go style of writing code (Emacs also 
helps), outside "if", "for", "switch" and maybe "select" (I really works 
with channels), I probably never need to write semicolon myself.

To avoid making myself looking stupid by not knowing why simple Go program 
doesn't compile, when I read part of spec  "Semicolons" 
(https://golang.org/ref/spec#Semicolons), I try to work out where these 
semicolons are placed. First rule is easy, but second "To allow complex 
statements to occupy a single line, a semicolon may be omitted before a 
closing ")" or "}".", is quite hard to me.

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.

Best
Kamil
piątek, 29 października 2021 o 19:05:02 UTC+2 patryk.w...@gmail.com 
napisał(a):

> In order to standardize something, you need to establish things
> thanks to which you are able to express what you want to say.
>
> For example a Notation.
>
> The Go Reference manual uses Extended Backus-Naur Form (EBNF) for that and 
> this part is just expressing that.
> Think of this point not as "Go documentation," but as establishing a "way 
> to communicate".
>
> The excerpt you are asking about defines Production's syntax:
> Production = production_name "=" [ Expression ] "." .
> and a little further down you have an explanation of what Productions is:
> Productions are expressions constructed from terms and the following 
> operators, in increasing precedence.
>
> So in other words, we are defining here the syntax that will be used later 
> in the documentation, not the specific fields
> and that is why you can not find "production_name" throughout the rest of 
> the docs.
> However, for example, hex_digit is a in-docs Production built similarly to 
> what you are looking for:
> hex_digit = "0" … "9" | "A" … "F" | "a" … "f" .
>
> Best Regards,
>
> On Fri, 29 Oct 2021 at 12:53, Kamil Ziemian  wrote:
>
>> From what I understand about EBNF production_name should be defined using 
>> EBNF notation in manner like below.
>>
>> production_name = something1 | something2
>>
>> But I don't see such definition in Spec.
>>
>> Best
>> Kamil
>>
>> czwartek, 28 października 2021 o 21:31:07 UTC+2 seank...@gmail.com 
>> napisał(a):
>>
>>> There isn't much to it, a "production_name" is just an identifier for 
>>> the set of values defined on the other side of the =, some of which may 
>>> also be identifiers that should be dereferenced/expanded
>>>
>>> If it helps, there's a wikipedia entry on it: 
>>> https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form
>>>
>>> On Thursday, October 28, 2021 at 7:33:27 PM UTC+2 kziem...@gmail.com 
>>> wrote:
>>>
 Hello,

 From what I understand proper Gopher read at least one time "The Go 
 Programming Language Specification" (https://golang.org/ref/spec) and 
 now I need to read it too.

 I learn something of Extended Backus-Naur Form to understand it, so if 
 I say something stupid beyond belief, I hope you will forgive me. In the 
 first part "Notation" (https://golang.org/ref/spec#Notation) I believe 
 that I understand meaning of all concepts except of "production_name". On 
 one hand "production_name" means that it is name of the production, not 
 rocket science here. On the other, after reading about EBNF I feel that I 
 should have more information about it. Can you explain it to me?

 Again I'm new to EBNF, so maybe this is stupid question.

 Best
 Kamil

 -- 
>> 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/02647258-d529-4dac-ac63-8c72874b4a89n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
>
> *Patryk Węgrzynek*
>
> Backend Developer
> Site Reliability Engineer
>
>

-- 
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/34207690-ba92-439b-b9f2-73163f75cd86n%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Patryk Węgrzynek]

In order to standardize something, you need to establish things
thanks to which you are able to express what you want to say.

For example a Notation.

The Go Reference manual uses Extended Backus-Naur Form (EBNF) for that and
this part is just expressing that.
Think of this point not as "Go documentation," but as establishing a "way
to communicate".

The excerpt you are asking about defines Production's syntax:
Production = production_name "=" [ Expression ] "." .
and a little further down you have an explanation of what Productions is:
Productions are expressions constructed from terms and the following
operators, in increasing precedence.

So in other words, we are defining here the syntax that will be used later
in the documentation, not the specific fields
and that is why you can not find "production_name" throughout the rest of
the docs.
However, for example, hex_digit is a in-docs Production built similarly to
what you are looking for:
hex_digit = "0" … "9" | "A" … "F" | "a" … "f" .

Best Regards,

On Fri, 29 Oct 2021 at 12:53, Kamil Ziemian  wrote:

> From what I understand about EBNF production_name should be defined using
> EBNF notation in manner like below.
>
> production_name = something1 | something2
>
> But I don't see such definition in Spec.
>
> Best
> Kamil
>
> czwartek, 28 października 2021 o 21:31:07 UTC+2 seank...@gmail.com
> napisał(a):
>
>> There isn't much to it, a "production_name" is just an identifier for the
>> set of values defined on the other side of the =, some of which may also be
>> identifiers that should be dereferenced/expanded
>>
>> If it helps, there's a wikipedia entry on it:
>> https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form
>>
>> On Thursday, October 28, 2021 at 7:33:27 PM UTC+2 kziem...@gmail.com
>> wrote:
>>
>>> Hello,
>>>
>>> From what I understand proper Gopher read at least one time "The Go
>>> Programming Language Specification" (https://golang.org/ref/spec) and
>>> now I need to read it too.
>>>
>>> I learn something of Extended Backus-Naur Form to understand it, so if I
>>> say something stupid beyond belief, I hope you will forgive me. In the
>>> first part "Notation" (https://golang.org/ref/spec#Notation) I believe
>>> that I understand meaning of all concepts except of "production_name". On
>>> one hand "production_name" means that it is name of the production, not
>>> rocket science here. On the other, after reading about EBNF I feel that I
>>> should have more information about it. Can you explain it to me?
>>>
>>> Again I'm new to EBNF, so maybe this is stupid question.
>>>
>>> Best
>>> Kamil
>>>
>>> --
> 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/02647258-d529-4dac-ac63-8c72874b4a89n%40googlegroups.com
> 
> .
>


-- 

*Patryk Węgrzynek*

Backend Developer
Site Reliability Engineer

-- 
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/CAFLRUz5VUT1SW9h9-NSdeUefCj2HF8_FW49L%3Dy7bR7EoY7HY0g%40mail.gmail.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Thank you Patryk Węgrzynek for these notes. I often feel uneasy when things
like "ways of comunications” are unclean to me just at the beginning of
reading of text. I like have everything clear at start and you help me
clear some mess in my head.

Best
Kamil

pt., 29 paź 2021 o 16:00 Kamil Ziemian  napisał(a):

> Thank you Jan Marcel, now I understand this part of Spec. I now will go
> back to read rest of it.
>
> Best
> Kamil
>
> piątek, 29 października 2021 o 13:29:16 UTC+2 Jan Mercl napisał(a):
>
>> On Fri, Oct 29, 2021 at 12:53 PM Kamil Ziemian 
>> wrote:
>> >
>> > From what I understand about EBNF production_name should be defined
>> using EBNF notation in manner like below.
>> >
>> > production_name = something1 | something2
>> >
>> > But I don't see such definition in Spec.
>>
>> Because production_name is a terminal symbol of the EBNF grammar per se.
>>
>> 
>> Lower-case production names are used to identify lexical tokens.
>> Non-terminals are in CamelCase.
>> 
>>
>> src: https://golang.org/ref/spec#Notation
>>
>> The above link defines a meta-grammar, ie. a grammar of the EBNF
>> grammar in which the actual Go EBNF grammar is later on defined. In
>> the Go case the terminals are really defined, like here
>> https://golang.org/ref/spec#Letters_and_digits.
>>
>> The EBNF grammar per se is outlined only loosely and is strictly not
>> complete in this case, so you're right. The reader is expected to
>> assume "usual" grammar of an identifier, like "a letter followed by 1
>> or more letters or digits", for example. The "real" definition of EBNF
>> can be found for example here:
>> https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form. It
>> seems too long to include in the Go specs, moreover I think it even
>> differs in some details.
>>
>> -j
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/xwavrjBZbeE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/413421f3-914c-4a71-8cd5-4464b8262802n%40googlegroups.com
> 
> .
>

-- 
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/CAB3gO8owOOfJzpUm_PPh8AKQ74m%2BD8GJFfCuS-CgjXx8q2j0nA%40mail.gmail.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Thank you Jan Marcel, now I understand this part of Spec. I now will go 
back to read rest of it.

Best
Kamil

piątek, 29 października 2021 o 13:29:16 UTC+2 Jan Mercl napisał(a):

> On Fri, Oct 29, 2021 at 12:53 PM Kamil Ziemian  wrote:
> >
> > From what I understand about EBNF production_name should be defined 
> using EBNF notation in manner like below.
> >
> > production_name = something1 | something2
> >
> > But I don't see such definition in Spec.
>
> Because production_name is a terminal symbol of the EBNF grammar per se.
>
> 
> Lower-case production names are used to identify lexical tokens.
> Non-terminals are in CamelCase.
> 
>
> src: https://golang.org/ref/spec#Notation
>
> The above link defines a meta-grammar, ie. a grammar of the EBNF
> grammar in which the actual Go EBNF grammar is later on defined. In
> the Go case the terminals are really defined, like here
> https://golang.org/ref/spec#Letters_and_digits.
>
> The EBNF grammar per se is outlined only loosely and is strictly not
> complete in this case, so you're right. The reader is expected to
> assume "usual" grammar of an identifier, like "a letter followed by 1
> or more letters or digits", for example. The "real" definition of EBNF
> can be found for example here:
> https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form. It
> seems too long to include in the Go specs, moreover I think it even
> differs in some details.
>
> -j
>

-- 
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/413421f3-914c-4a71-8cd5-4464b8262802n%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Jan Mercl]

On Fri, Oct 29, 2021 at 12:53 PM Kamil Ziemian  wrote:
>
> From what I understand about EBNF production_name should be defined using 
> EBNF notation in manner like below.
>
> production_name = something1 | something2
>
> But I don't see such definition in Spec.

Because production_name is a terminal symbol of the EBNF grammar per se.


Lower-case production names are used to identify lexical tokens.
Non-terminals are in CamelCase.


src: https://golang.org/ref/spec#Notation

The above link defines a meta-grammar, ie. a grammar of the EBNF
grammar in which the actual Go EBNF grammar is later on defined. In
the Go case the terminals are really defined, like here
https://golang.org/ref/spec#Letters_and_digits.

The EBNF grammar per se is outlined only loosely and is strictly not
complete in this case, so you're right. The reader is expected to
assume "usual" grammar of an identifier, like "a letter followed by 1
or more letters or digits", for example. The "real" definition of EBNF
can be found for example here:
https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form. It
seems too long to include in the Go specs, moreover I think it even
differs in some details.

-j

-- 
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/CAA40n-V%2BRV3SV1uJPTMSujM59o%3Dq-y5Y9qe%2BYrV36xjjk9G99w%40mail.gmail.com.

[go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

>From what I understand about EBNF production_name should be defined using 
EBNF notation in manner like below.

production_name = something1 | something2

But I don't see such definition in Spec.

Best
Kamil

czwartek, 28 października 2021 o 21:31:07 UTC+2 seank...@gmail.com 
napisał(a):

> There isn't much to it, a "production_name" is just an identifier for the 
> set of values defined on the other side of the =, some of which may also be 
> identifiers that should be dereferenced/expanded
>
> If it helps, there's a wikipedia entry on it: 
> https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form
>
> On Thursday, October 28, 2021 at 7:33:27 PM UTC+2 kziem...@gmail.com 
> wrote:
>
>> Hello,
>>
>> From what I understand proper Gopher read at least one time "The Go 
>> Programming Language Specification" (https://golang.org/ref/spec) and 
>> now I need to read it too.
>>
>> I learn something of Extended Backus-Naur Form to understand it, so if I 
>> say something stupid beyond belief, I hope you will forgive me. In the 
>> first part "Notation" (https://golang.org/ref/spec#Notation) I believe 
>> that I understand meaning of all concepts except of "production_name". On 
>> one hand "production_name" means that it is name of the production, not 
>> rocket science here. On the other, after reading about EBNF I feel that I 
>> should have more information about it. Can you explain it to me?
>>
>> Again I'm new to EBNF, so maybe this is stupid question.
>>
>> Best
>> Kamil
>>
>>

-- 
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/02647258-d529-4dac-ac63-8c72874b4a89n%40googlegroups.com.

[go-nuts] Re: Amateur's questions about "Go lang spec"

[Sean Liao]

There isn't much to it, a "production_name" is just an identifier for the 
set of values defined on the other side of the =, some of which may also be 
identifiers that should be dereferenced/expanded

If it helps, there's a wikipedia entry on 
it: https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form

On Thursday, October 28, 2021 at 7:33:27 PM UTC+2 kziem...@gmail.com wrote:

> Hello,
>
> From what I understand proper Gopher read at least one time "The Go 
> Programming Language Specification" (https://golang.org/ref/spec) and now 
> I need to read it too.
>
> I learn something of Extended Backus-Naur Form to understand it, so if I 
> say something stupid beyond belief, I hope you will forgive me. In the 
> first part "Notation" (https://golang.org/ref/spec#Notation) I believe 
> that I understand meaning of all concepts except of "production_name". On 
> one hand "production_name" means that it is name of the production, not 
> rocket science here. On the other, after reading about EBNF I feel that I 
> should have more information about it. Can you explain it to me?
>
> Again I'm new to EBNF, so maybe this is stupid question.
>
> Best
> Kamil
>
>

-- 
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/18c916bf-a4b3-4ab4-a3c7-b67e925b13b9n%40googlegroups.com.