[go-nuts] Slices, backing array, goroutines, perhaps Considerations for Go2

[atd...@gmail.com]

Hello,

I've just realized that slices were much more delicate to use than 
initially thought. The main issue is that when slices share the same 
backing array, it is too easy to inadvertently have an unprotected 
concurrent Read/Write  if one is not careful.
That can easily happen for a struct that has a field of type slice for 
instance. The object might be safe to copy and pass around to multiple 
goroutine but reading a value from the slice field can still be problematic 
if there is a write at the same time on one of the object's slice field.

This is not a proposal but for later, would it make sense to have slices 
become real snapshots (immutable) or copy/allocate on mutation?
It will probably have perf repercussions.

Or alternatively a tool that alerts of cases where there are such case of 
unprotected concurrent use (perhaps the race detector already does this)

Even better is if that's a non argument because the cases where it's happen 
in real world code is sparse but I must admit that it took me a long time 
to think about this and now, I'm worried that it's a mistake too easily 
made.

Also, I do not remember the specifics of the map code, but what happens for 
a map of slices? Do the slice elements share the backing array? 



-- 
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/bf49fac1-1206-495b-ba69-2eccc3504a84%40googlegroups.com.

[go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[atd...@gmail.com]

Hi,

Thank you for the response.

My issue is not really about append but can be illustrated by this :

https://play.golang.org/p/YZlo1mqGDLz

On Saturday, October 26, 2019 at 2:27:06 PM UTC+2, Gert wrote:
>
> Sorry, the performance cost is to high. But you can practice a few 
> programming habits that can prevent this, like use x = append(x, y) and 
> never x = append(y, x) Basically we only need a Go proverb bible mentioned 
> in one of Rob Pike's talks and we will be fine :)
>
> On Saturday, October 26, 2019 at 1:40:23 PM UTC+2, atd...@gmail.com wrote:
>>
>> Hello,
>>
>> I've just realized that slices were much more delicate to use than 
>> initially thought. The main issue is that when slices share the same 
>> backing array, it is too easy to inadvertently have an unprotected 
>> concurrent Read/Write  if one is not careful.
>> That can easily happen for a struct that has a field of type slice for 
>> instance. The object might be safe to copy and pass around to multiple 
>> goroutine but reading a value from the slice field can still be problematic 
>> if there is a write at the same time on one of the object's slice field.
>>
>> This is not a proposal but for later, would it make sense to have slices 
>> become real snapshots (immutable) or copy/allocate on mutation?
>> It will probably have perf repercussions.
>>
>> Or alternatively a tool that alerts of cases where there are such case of 
>> unprotected concurrent use (perhaps the race detector already does this)
>>
>> Even better is if that's a non argument because the cases where it's 
>> happen in real world code is sparse but I must admit that it took me a long 
>> time to think about this and now, I'm worried that it's a mistake too 
>> easily made.
>>
>> Also, I do not remember the specifics of the map code, but what happens 
>> for a map of slices? Do the slice elements share the backing array? 
>>
>>
>>
>>

-- 
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/cf96053e-1209-459a-bc80-830690da80b0%40googlegroups.com.

[go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[atd...@gmail.com]

I get that we can do that but it's not strictly about slices operations 
such as appending or copying.
Of course, we could copy slices all the time but then there is no benefit 
in having them and it is not ergonomic as your example shows, nor does it 
fit your performance cost requirements.

If you look at the code snippet I posted, I am merely assigning a value of 
type slice to a struct field. Now, that struct can be copied a number of 
times without its actual value changing. It looks immutable in some sense.  
BUT, it's actually implicitly tied to an object that is mutable (backing 
array) and nowhere have we made sure that the mutation of this backing 
array is safe.

On Saturday, October 26, 2019 at 7:20:31 PM UTC+2, Gert wrote:
>
> Correct, so basically avoid x := y[i:j] if you actually meant copy
>
> https://golang.org/ref/spec#Appending_and_copying_slices
>
> var a = [...]int{0, 1, 2, 3, 4, 5, 6, 7}
> var s = make([]int, 6)
> var b = make([]byte, 5)
> n1 := copy(s, a[0:])// n1 == 6, s == []int{0, 1, 2, 3, 4, 5}
> n2 := copy(s, s[2:])// n2 == 4, s == []int{2, 3, 4, 5, 4, 5}
> n3 := copy(b, "Hello, World!")  // n3 == 5, b == []byte("Hello")
>
>
> On Saturday, October 26, 2019 at 3:02:37 PM UTC+2, atd...@gmail.com wrote:
>>
>> Hi,
>>
>> Thank you for the response.
>>
>> My issue is not really about append but can be illustrated by this :
>>
>> https://play.golang.org/p/YZlo1mqGDLz
>>
>> On Saturday, October 26, 2019 at 2:27:06 PM UTC+2, Gert wrote:
>>>
>>> Sorry, the performance cost is to high. But you can practice a few 
>>> programming habits that can prevent this, like use x = append(x, y) and 
>>> never x = append(y, x) Basically we only need a Go proverb bible mentioned 
>>> in one of Rob Pike's talks and we will be fine :)
>>>
>>> On Saturday, October 26, 2019 at 1:40:23 PM UTC+2, atd...@gmail.com 
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I've just realized that slices were much more delicate to use than 
>>>> initially thought. The main issue is that when slices share the same 
>>>> backing array, it is too easy to inadvertently have an unprotected 
>>>> concurrent Read/Write  if one is not careful.
>>>> That can easily happen for a struct that has a field of type slice for 
>>>> instance. The object might be safe to copy and pass around to multiple 
>>>> goroutine but reading a value from the slice field can still be 
>>>> problematic 
>>>> if there is a write at the same time on one of the object's slice field.
>>>>
>>>> This is not a proposal but for later, would it make sense to have 
>>>> slices become real snapshots (immutable) or copy/allocate on mutation?
>>>> It will probably have perf repercussions.
>>>>
>>>> Or alternatively a tool that alerts of cases where there are such case 
>>>> of unprotected concurrent use (perhaps the race detector already does this)
>>>>
>>>> Even better is if that's a non argument because the cases where it's 
>>>> happen in real world code is sparse but I must admit that it took me a 
>>>> long 
>>>> time to think about this and now, I'm worried that it's a mistake too 
>>>> easily made.
>>>>
>>>> Also, I do not remember the specifics of the map code, but what happens 
>>>> for a map of slices? Do the slice elements share the backing array? 
>>>>
>>>>
>>>>
>>>>

-- 
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/ab159b59-af74-4813-8c77-9b5b3b84ef0d%40googlegroups.com.

[go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[atd...@gmail.com]

To add to this issue, that's a problem that is also related to how type 
equality is treated in the spec and deep equality. If we have some kind of 
"snapshot" slices for instance, an equality can be determined for these 
(with some other things to consider) and for structs with fields that are 
"snapshot" slices.


On Saturday, October 26, 2019 at 7:49:50 PM UTC+2, atd...@gmail.com wrote:
>
> I get that we can do that but it's not strictly about slices operations 
> such as appending or copying.
> Of course, we could copy slices all the time but then there is no benefit 
> in having them and it is not ergonomic as your example shows, nor does it 
> fit your performance cost requirements.
>
> If you look at the code snippet I posted, I am merely assigning a value of 
> type slice to a struct field. Now, that struct can be copied a number of 
> times without its actual value changing. It looks immutable in some sense.  
> BUT, it's actually implicitly tied to an object that is mutable (backing 
> array) and nowhere have we made sure that the mutation of this backing 
> array is safe.
>
> On Saturday, October 26, 2019 at 7:20:31 PM UTC+2, Gert wrote:
>>
>> Correct, so basically avoid x := y[i:j] if you actually meant copy
>>
>> https://golang.org/ref/spec#Appending_and_copying_slices
>>
>> var a = [...]int{0, 1, 2, 3, 4, 5, 6, 7}
>> var s = make([]int, 6)
>> var b = make([]byte, 5)
>> n1 := copy(s, a[0:])// n1 == 6, s == []int{0, 1, 2, 3, 4, 5}
>> n2 := copy(s, s[2:])// n2 == 4, s == []int{2, 3, 4, 5, 4, 5}
>> n3 := copy(b, "Hello, World!")  // n3 == 5, b == []byte("Hello")
>>
>>
>> On Saturday, October 26, 2019 at 3:02:37 PM UTC+2, atd...@gmail.com 
>> wrote:
>>>
>>> Hi,
>>>
>>> Thank you for the response.
>>>
>>> My issue is not really about append but can be illustrated by this :
>>>
>>> https://play.golang.org/p/YZlo1mqGDLz
>>>
>>> On Saturday, October 26, 2019 at 2:27:06 PM UTC+2, Gert wrote:
>>>>
>>>> Sorry, the performance cost is to high. But you can practice a few 
>>>> programming habits that can prevent this, like use x = append(x, y) and 
>>>> never x = append(y, x) Basically we only need a Go proverb bible mentioned 
>>>> in one of Rob Pike's talks and we will be fine :)
>>>>
>>>> On Saturday, October 26, 2019 at 1:40:23 PM UTC+2, atd...@gmail.com 
>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I've just realized that slices were much more delicate to use than 
>>>>> initially thought. The main issue is that when slices share the same 
>>>>> backing array, it is too easy to inadvertently have an unprotected 
>>>>> concurrent Read/Write  if one is not careful.
>>>>> That can easily happen for a struct that has a field of type slice for 
>>>>> instance. The object might be safe to copy and pass around to multiple 
>>>>> goroutine but reading a value from the slice field can still be 
>>>>> problematic 
>>>>> if there is a write at the same time on one of the object's slice field.
>>>>>
>>>>> This is not a proposal but for later, would it make sense to have 
>>>>> slices become real snapshots (immutable) or copy/allocate on mutation?
>>>>> It will probably have perf repercussions.
>>>>>
>>>>> Or alternatively a tool that alerts of cases where there are such case 
>>>>> of unprotected concurrent use (perhaps the race detector already does 
>>>>> this)
>>>>>
>>>>> Even better is if that's a non argument because the cases where it's 
>>>>> happen in real world code is sparse but I must admit that it took me a 
>>>>> long 
>>>>> time to think about this and now, I'm worried that it's a mistake too 
>>>>> easily made.
>>>>>
>>>>> Also, I do not remember the specifics of the map code, but what 
>>>>> happens for a map of slices? Do the slice elements share the backing 
>>>>> array? 
>>>>>
>>>>>
>>>>>
>>>>>

-- 
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/cfa2fdcc-11f3-4400-98df-ab4193c2171b%40googlegroups.com.

Re: [go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[atd...@gmail.com]

On Saturday, October 26, 2019 at 9:47:39 PM UTC+2, Ian Lance Taylor wrote:
>
> On Sat, Oct 26, 2019 at 10:50 AM atd...@gmail.com  > wrote: 
> > 
> > I get that we can do that but it's not strictly about slices operations 
> such as appending or copying. 
> > Of course, we could copy slices all the time but then there is no 
> benefit in having them and it is not ergonomic as your example shows, nor 
> does it fit your performance cost requirements. 
> > 
> > If you look at the code snippet I posted, I am merely assigning a value 
> of type slice to a struct field. Now, that struct can be copied a number of 
> times without its actual value changing. It looks immutable in some sense. 
>  BUT, it's actually implicitly tied to an object that is mutable (backing 
> array) and nowhere have we made sure that the mutation of this backing 
> array is safe. 
>
> For better or for worse, the Go language has shared state.  This is 
> most obvious when using pointers: if you copy a pointer, you do not 
> copy the memory to which that pointer points.  If that is clear, then 
> the thing to remember about slices is that they are pointers. 
> Pointers in Go do not permit arithmetic.  

 

> Slices in Go are pointers 
> that permit bounded arithmetic. 
>
> Oh, I hadn't thought about it that way! Interesting.
I still feel like there should be a way to reign in the amount of shared 
state in the cases of these "fat" pointers a little bit. Or at least, 
inspect it, warn about it more bceause most people seem to think that 
slices are just infinite arrays (hence the need for the extra-level of 
indirection/pointer). 
But perhaps, the coding patterns/idioms make it a non issue.  For future 
considerations I guess.

> Ian 
>

-- 
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/be142bd1-cbfc-4652-9381-c05f19f5ce81%40googlegroups.com.

Re: [go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[atd...@gmail.com]

Yes, the issue is twofold.

Because everything is passed by "copy", it might feel safe to pass around 
structs with slice fields, especially and perhaps unknowingly as "interior 
fat pointers" in structs. 
But, one should remember that these objects are always shallow copies in 
the sense that map/slices/functions will refer to the same underlying 
elements and not be dissociated. 
Thus it could be nice to have a way to enforce deeper copies at the 
language level as well.

The second issue that is related to the first one is that in the case of 
mutliple access by different goroutines, 
this problem can be compounded since the objects can seem to be naturally 
thread safe but the slice operations for instance are not. 
Perhaps is it even the same issue if we send slices through channels if for 
some reason, the backing arrays are shared, I don't know. 

Main thing is that I don't trust the fact that many beginners will have 
thought about this (or perhaps it is just me who didn't). 
Especially when passing objects to different functions that may mutate an 
object internals thinking it is just a copy.

On Monday, October 28, 2019 at 9:44:24 AM UTC+1, rog wrote:
>
>
>
> On Sun, 27 Oct 2019, 21:31 Dan Kortschak, > 
> wrote:
>
>> This is not necessarily due to races. You can have this exact situation
>> occurring in single threaded code. I don't think any mention of race
>> issues was made here.
>>
>
> The thread subject mentions goroutines and the original message talks 
> specifically about concurrent access, which sounds very much like it's 
> race-related to me.
>
>>
>> On Sun, 2019-10-27 at 08:53 +, roger peppe wrote:
>> > On Sun, 27 Oct 2019, 00:04 Gert, > 
>> wrote:
>> > 
>> > > I believe it's going to be to hard to write a go vet analyser that
>> > > could
>> > > warn to detect unintended state change on a array from two
>> > > different
>> > > pointers.
>> > > 
>> > 
>> > Isn't that why we have the race detector?
>> > 
>> > -- 
>> > > 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 golan...@googlegroups.com .
>> > > To view this discussion on the web visit
>> > > 
>>
>> https://groups.google.com/d/msgid/golang-nuts/30ac16bc-bc70-40a6-bc79-f41e3536d144%40googlegroups.com
>> > > <
>> > > 
>> https://groups.google.com/d/msgid/golang-nuts/30ac16bc-bc70-40a6-bc79-f41e3536d144%40googlegroups.com?utm_medium=email&utm_source=footer
>> > > >
>> > > .
>> > > 
>> > 
>> > 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7560f6d2-ca55-48ea-a874-5b972ddf40a6%40googlegroups.com.

Re: [go-nuts] Re: Golang should have a center packages index hosting like npm, rust crates

[atd...@gmail.com]

On Thursday, October 27, 2016 at 4:41:42 PM UTC+2, Michal Bohuslávek wrote:
>
> It's not much of a penalisation IMO. It doesn't have to be a large message 
> in red saying: "The author of this package doesn't use semantic versioning. 
> Be careful!". I mean the list of versions can only appear if there are some 
> versions. That way it wouldn't penalise a), although I can't come up with a 
> good reason not to tag versions apart from b).
>
> When it comes to b), there could be some rule for that case. Such authors 
> could for example put their stable API in a branch called "stable" or 
> something like that.
>

That wouldn't work with the way the language is structured (imports).
Just having a version tag is perhaps necessary, but, alas, not sufficient 
to deal with the entirety of dependency discovery/management.

We have some primitives (canonical imports etc...). Solving availability by 
redundancy(since part of the issue is about distributed systems) may also 
tie into import rewritting, or import aliasing.. which could be done a few 
different ways.

It's not a simple problem.
 

>
> Dne čtvrtek 27. října 2016 1:39:47 UTC+1 Axel Wagner napsal(a):
>>
>> So, the idea is to penalize people who a) have a different opinion about 
>> the usefulness of versioning or b) keep their APIs stable and don't see a 
>> need to version something that never changes?
>>
>> Needless to say, I consider that a bad idea (given, that I have strongly 
>> differing opinions about the usefulness of versioning). Why can't the idea 
>> not succeed based on it's own merit (or lack thereof)?
>>
>> But whatever. Set minds won't be swayed by arguments, I guess.
>>
>> I'll also point out (again) that this thread, originally, was about a 
>> central repository. Not about versioning.
>>
>> On Wed, Oct 26, 2016 at 10:53 PM, Edward Muller  
>> wrote:
>>
>>> Yes, use that proposal's format.
>>>
>>> Re: godoc. Great idea. if no one else is interested in doing the work 
>>> I'll be happy to take a look into it. I've been looking for an excuse to 
>>> work with gddo
>>>
>>> On Wed, Oct 26, 2016 at 1:42 PM Dave Cheney  wrote:
>>>
 Indeed. If only there was some standard we could use


 https://github.com/golang/proposal/blob/master/design/12302-release-proposal.md#tag-format

 On Thu, Oct 27, 2016 at 6:08 AM, Nate Finch  wrote:
 > Listing versions on godoc is an awesome idea.  Peer pressure goes a 
 long way
 > toward changing individual minds and eventually a community.  
 Something as
 > simple as sorting projects with tagged versions higher and displaying 
 them
 > prominently on the project's godoc page (with the ability to look at 
 godoc
 > for each version) would go a long way toward encouraging people to 
 tag their
 > releases.  I know it would get me off my butt to tag my projects.
 >
 > On Wednesday, October 26, 2016 at 11:37:54 AM UTC-4, 
 mbohu...@gmail.com
 > wrote:
 >>
 >> I was just wondering whether a simple list of available versions at 
 the
 >> top of a package's godoc.org page wouldn't somehow force package 
 authors to
 >> start tagging. There could be some kind of message if there are no 
 available
 >> versions.
 >> There would obviously have to be some benefit for those who tag, or 
 some
 >> restriction for those who don't, in order to change the current 
 situation.

 --
 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.
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] httpsnoop, an easy way to capture http related metrics (response time, bytes written, and http status code)

[atd...@gmail.com]

I haven't thought too much about it but there is possibly an alternative 
logic by having the wrappers add a Wrap() http.ResponseWriter that would 
return the wrappee.

So first, one would test for that Wrapper interface, then return the 
wrappee if the test turns out to be positive. Then one could assert for 
various interfaces on this wrappee.

Something to think about.

On Thursday, November 10, 2016 at 12:09:32 PM UTC+1, Felix Geisendoerfer 
wrote:
>
> Hi all,
>
> while working on instrumenting my application, I ran into the fact that 
> capturing metrics such as status codes from my own http.Handlers is 
> surprisingly difficult to get right.
>
> Therefor I created a package that hopefully avoids most of the common 
> pitfalls. 
>
> https://github.com/felixge/httpsnoop
>
> I would love for net/http experts to take a look at the "Why this package 
> exists" section of the README, as well as the horrible hack required to 
> make things work:
>
> https://github.com/felixge/httpsnoop/blob/master/wrap.go#L44-L163
>
> Please let me know if you have suggestions for simpler approaches and/or 
> spot any bugs in my implementation.
>
> Thanks a lot!
> Felix Geisendörfer
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: [ANN] httpsnoop, an easy way to capture http related metrics (response time, bytes written, and http status code)

[atd...@gmail.com]

The goal is to check whether a http.ResponseWriter is a wrapper around 
another http.ResponseWriter. If so, we can check what the wrappee 
implements besides ServeHTTP(...). Maybe it is itself a wrapper. Maybe it 
is a Hijacker or ReadCloser...

If this wrappee is itself a wrapper, the logic is recursive.

This way, the top wrapper, which is a http.ResponseWriter, does not need to 
bear assumptions about what any of the wrappee may have implemented. It 
just asserts for what it is interested in.

https://play.golang.org/p/cBeJHExtOh

Now, I don't know if it solves your issue but that's a quick thought.



On Friday, November 11, 2016 at 11:42:38 AM UTC+1, Felix Geisendörfer wrote:
>
> I haven't thought too much about it but there is possibly an alternative 
> logic by having the wrappers add a Wrap() http.ResponseWriter that would 
> return the wrappee.
>
> So first, one would test for that Wrapper interface, then return the 
> wrappee if the test turns out to be positive. Then one could assert for 
> various interfaces on this wrappee.
>
> Something to think about.
>
>
> Maybe I’m misunderstanding your idea, but wouldn’t this require having to 
> go over every handler used by the application in order to see where this is 
> needed?
>
> If yes, then I don’t like it, because that’s exactly what I was trying to 
> avoid. The whole idea was to make the wrapping/instrumentation transparent 
> to all handlers.
>
> Cheers
> Felix
>
> On 11 Nov 2016, at 11:35, atd...@gmail.com > 
> wrote:
>
> I haven't thought too much about it but there is possibly an alternative 
> logic by having the wrappers add a Wrap() http.ResponseWriter that would 
> return the wrappee.
>
> So first, one would test for that Wrapper interface, then return the 
> wrappee if the test turns out to be positive. Then one could assert for 
> various interfaces on this wrappee.
>
> Something to think about.
>
> On Thursday, November 10, 2016 at 12:09:32 PM UTC+1, Felix Geisendoerfer 
> wrote:
>>
>> Hi all,
>>
>> while working on instrumenting my application, I ran into the fact that 
>> capturing metrics such as status codes from my own http.Handlers is 
>> surprisingly difficult to get right.
>>
>> Therefor I created a package that hopefully avoids most of the common 
>> pitfalls. 
>>
>> https://github.com/felixge/httpsnoop
>>
>> I would love for net/http experts to take a look at the "Why this package 
>> exists" section of the README, as well as the horrible hack required to 
>> make things work:
>>
>> https://github.com/felixge/httpsnoop/blob/master/wrap.go#L44-L163
>>
>> Please let me know if you have suggestions for simpler approaches and/or 
>> spot any bugs in my implementation.
>>
>> Thanks a lot!
>> Felix Geisendörfer
>>
>
> -- 
> 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/-I5IZgJosYE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Interface vs first-class function

[atd...@gmail.com]

You have less indirection with the interface. More ergonomic.
An interface also allows to define a set of constraints whereas the first 
class function does not coerce you into having a defined set of function 
arguments.

On Sunday, November 20, 2016 at 6:22:57 AM UTC+1, Henry wrote:
>
> Hi,
>
> I am wondering from best practice point of view whether it is better to 
> use interface or first-class function, especially considering that Go 
> encourages the use of small interfaces. Here is an example:
>
> type SomethingDoer interface{
>DoSomething(data Data)
> }
>
> func PerformWork(doer SomethingDoer){
>//...
> }
>
> Or 
>
> type SomethingDoer func(Data)
>
> func PerformWork(doer SomethingDoer){
>//...
> }
>
> Is there some sort of a guideline when to use one vs the other? They seem 
> like redundant features to me.
>
> Thanks
>
> Henry
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Interface vs first-class function

[atd...@gmail.com]

To be more concrete, taking your example, PerformWork cannot be easily 
customized according to the type of first class function that returns a 
func(Data).
Actually it goes further, because that first class function can "only" 
return a func(Data) and not multiple functions.

With an interface, it's equivalent to being able to pass a first class 
function returning possibly multiple values of which at least one is of 
type func(Data).
More than that, we have ways to discover some of the other return values 
and adapt PerformWork execution accordingly.



On Sunday, November 20, 2016 at 1:25:11 PM UTC+1, atd...@gmail.com wrote:
>
> You have less indirection with the interface. More ergonomic.
> An interface also allows to define a set of constraints whereas the first 
> class function does not coerce you into having a defined set of function 
> arguments.
>
> On Sunday, November 20, 2016 at 6:22:57 AM UTC+1, Henry wrote:
>>
>> Hi,
>>
>> I am wondering from best practice point of view whether it is better to 
>> use interface or first-class function, especially considering that Go 
>> encourages the use of small interfaces. Here is an example:
>>
>> type SomethingDoer interface{
>>DoSomething(data Data)
>> }
>>
>> func PerformWork(doer SomethingDoer){
>>//...
>> }
>>
>> Or 
>>
>> type SomethingDoer func(Data)
>>
>> func PerformWork(doer SomethingDoer){
>>//...
>> }
>>
>> Is there some sort of a guideline when to use one vs the other? They seem 
>> like redundant features to me.
>>
>> Thanks
>>
>> Henry
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why doens't function type support comparision but channel type does?

[atd...@gmail.com]

It highly depends on what you define a function.

If it's in the mathematical sense, it won't work.

A function, in practice, is a small embedded program (stored as a valur in 
the main program). It's not just the text (semantics). It's defined 
somewhere (in some package etc...)

That's all those things that probably need to be equal.

On Friday, November 25, 2016 at 12:28:52 PM UTC+1, Jesper Louis Andersen 
wrote:
>
> Indeed, the whole point is that you shouldn't add equality of functions to 
> a language. I disagree that the formal proof of function equivalence is a 
> red herring. Rather, it is the crux of the problem: the only sensible 
> equality of functions turns out to be observational equality, which is 
> non-trivial to handle. But in order to understand that, you eventually have 
> to discuss what it would take to add such a thing to a language. Talk is 
> rather cheap compared to writing a robust compiler with deterministic 
> interfaces. In the same vein, I don't think float32 and float64 should be 
> eqtypes either. Nor, can it be argued, should a map or array because their 
> equivalence isn't an O(1) operation.
>
> On Fri, Nov 25, 2016 at 11:38 AM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>> I think, in the context of this thread, talking about formally proving 
>> whether two functions produces equivalent results is a red herring.
>>
>> a) It is an impossible problem to solve in general, so you'd need to 
>> restrict your definition to some provable subset
>> b) That will be impossible to put in a spec in any sensible way without 
>> blowing it up immensely
>> c) Even if, that subset can't include side-effects, which would make it 
>> completely useless for go
>> and d) even if you could, requiring to implement those proofs would make 
>> it highly unlikely if not impossible, that more than one (or a very small 
>> handful) go-implementation exists, defeating the point of a good spec in 
>> the first place (think about, for example, what that would mean for 
>> gopherjs or gomobile, where a func() can be implemented by opaque 
>> javascript/asm/dalvik bytecode/compiled machine code).
>>
>> If you want to debate the finer points of such proof engines for go 
>> existing as a tool separate from the language, I think that should go in a 
>> separate thread. I don't think it can be sensibly argued that it should 
>> become part of the language as the equality operator on func's.
>>
>> On Fri, Nov 25, 2016 at 11:05 AM, Jesper Louis Andersen <
>> jesper.lou...@gmail.com > wrote:
>>
>>>
>>> On Fri, Nov 25, 2016 at 12:30 AM Michael Jones >> > wrote:
>>>
 This is very nice! However, am i right in understanding that the magic 
 is in knowing the text of the program--the fact that there are untaken 
 branches? If so, this is not simply a 'behavioral' verification...it knows 
 about the construction of the code and not just its behavior. Maybe I was 
 unclear.
  

>>>
>>> Indeed you are right. This requires the ability to work on the program 
>>> text. It is a bit too hard to work on the output assembly for the program. 
>>> The advantage of a model-checker or a probalistic method such as 
>>> "testing/quick" is that they regard the system-under-test as a black box.
>>>
>>> This fact can be used in numerous ways. The most powerful one is that 
>>> once you have a specification model, in *any* programming language, it 
>>> applies to any system implementing that model, in *any* language. This has 
>>> been used historically for checking protocols for correctness, where the 
>>> specification were written in some high-level language (Haskell, Erlang) 
>>> but the code being tested were run in a low-level language (C, typically).
>>>
>>> In short, no single method applies in every case. Figuring out if two 
>>> programs are observationally equivalent usually requires one to exploit the 
>>> structure of the program text. Because from that structure the proof or 
>>> search strategy can be extracted.
>>>  
>>>
>> -- 
>>>
>> 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 .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] CFG for a Go program

[atd...@gmail.com]

I  concur.

On Monday, November 28, 2016 at 4:35:13 AM UTC+1, Michael Jones wrote:
>
> Details of this would make a great Go Blog post…
>
>  
>
> *From: *adonovan via golang-nuts >
> *Reply-To: *>
> *Date: *Sunday, November 27, 2016 at 6:07 PM
> *To: *golang-nuts >
> *Cc: *>
> *Subject: *Re: [go-nuts] CFG for a Go program
>
>  
>
> If you're building tools for source code analysis, you may find the 
> golang.org/x/go/ssa representation easier to work with than the internals 
> of the compiler.  Build and run this command to see an example:
>
>  
>
>   $ go get golang.org/x/tools/cmd/ssadump
>
>   $ ssadump -build=F fmt
>
>  
>
> Alternatively, the cmd/vet tool in the standard library has an internal 
> subpackage that constructs the control-flow graph of a function.  In this 
> representation, each block contains a sequence of Go statements and 
> expressions, not low-level SSA instructions.
>
>  
>
> Which of these forms of control-flow graph is most appropriate depends on 
> the (unmentioned) problem you're trying to solve.
>
> -- 
> 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 .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: What lead to the versionning debate?

[atd...@gmail.com]

That's somewhat the intent in enabling the timestamping of packages 
especially wrt. library-vendored package.
Flattening dependencies will still be needed but it would be simply a 
matter of switching a package to the latest package release that a package 
may have vendored.

But again, I would not build a solution by strictly imitating vcs or other 
package managers from a methodology point of view. They do not handle 
packages the same so the solution has to be different.

I firmly believe that the current assumptions held by Go tooling can help 
us find a quite simple(r) solution (than already exists for other 
languages).

On Tuesday, August 2, 2016 at 6:17:35 AM UTC+2, Lucio wrote:
>
>
>
> On Saturday, 30 July 2016 02:52:25 UTC+2, Matt Harden wrote:
>>
>> I like submodules, but they do only work when you're using git and only 
>> vendoring projects that also use git.
>>
>>
>>>
>>> It seems to me that the solution is staring us in the face. I know 
> nothing about git submodules, but they have been raised in this forum 
> before and the only criticism has been that no other VCS has them. If they 
> accomplish what Go developers need, then Go must model any solution on them.
>
> It surely does not make sense to overlook them because no other VCS has 
> them: in favour of what? No other VCS has anything better or even as good. 
> So, within reasonable limits, (a) Go needs to adopt Git submodules and (b) 
> Go must provide analogous tooling for alternative VCSs.
>
> Inventing something totally orthogonal to serve the same purpose would be 
> unreasonable.
>
> I appreciate that Git submodules are not the final answer, but I do 
> presume that they ought to be the foundations for any discussion.
>
> Lucio.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: What lead to the versionning debate?

[atd...@gmail.com]

Indeed, that's where we are coming short. The Go ecosystem does not own its 
package releasing process. (with a release identification scheme that may 
different from semver since we do not need to worry about major versions 
for reasons of different release semantics)

A `go release` command that would prepare a package for release could be 
the addition required. 

It will most likely  require to have a centralization of these package 
releases. Declined under a solution that can be internal for companies that 
need a tighter control over their dependencies OR fully web facing for 
gophers in the large).

I say package releases, but the repository can be anywhere people want, I 
don't think Google has to deal with the hosting of repos.

On Tuesday, August 2, 2016 at 10:20:59 AM UTC+2, Dave Cheney wrote:
>
> That's somewhat the intent in enabling the timestamping of packages 
>> especially wrt. library-vendored package.
>> Flattening dependencies will still be needed but it would be simply a 
>> matter of switching a package to the latest package release that a package 
>> may have vendored.
>>
>>
> To do this you need to have some _machine consumable_ notion of what is 
> the "latest release" of a package. This currently doesn't exist for Go 
> projects. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: What lead to the versionning debate?

[atd...@gmail.com]

Having an interface between go get and the location of the repositories 
should really allow people to move packages around at will provided the 
registration of a package provides a canonical import path. (and a facility 
for the declaration of mirrors)

Now, to accomodate with vcs and demands for reproducible builds (which 
require segregation of the dependencies per project), perhaps the go tool 
could allow switching between multiple $GOPATH. (just to avoid different 
project builds conflicting at the vcs level).

Also binaries may benefit from these changes if they record the source 
release point they were compiled from.

Go gets it mostly right because the canonical package path expect backward 
compatibility. We shouldn't need SAT solvers to resolve dependencies 
normally. :)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Namespacing hack using method on empty type

[atd...@gmail.com]

No it can have its uses.

It really depends on what you are doing. However, I've never done this as a 
way to declare some kind of namespace.

Typically, I use that in testing when I want a dummy type to implement an 
interface.

That's just an example.

It can be used also if you export the struct type. That allows to transfer 
a group of functions (closer to your idea of namespace).
Instead of exporting each function separately.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How to check that a Go package has not been modified?

[atd...@gmail.com]

Would a md5 hash suffice?

I mean, it is probably easy to create collisions, but the source still 
needs to compile so...

Or an md5 hash and using go/types to make sure that any object escaping the 
package boundaries is still present and none other have been added.

Any idea?


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How to check that a Go package has not been modified?

[atd...@gmail.com]

I'm a bit uneasy about this. Since checksumming is not collision-resistant, 
I would be careful just relying on this.
The goal was to avoid diffing files but I don't know what is the fastest 
way.

In any case, I guess a checksum is not enough to guarantee file integrity 
(against malice). Maybe adding file size would do.

On Wednesday, August 3, 2016 at 7:36:36 PM UTC+2, Daniel Theophanes wrote:
>
> What is the purpose of this? For instance, In govendor the hash of the 
> files, file names, and path is computed and recorded. That way if they are 
> modified it is detected. So yeah, md5 or blake2 would work just fine.
>
> On Wednesday, August 3, 2016 at 10:14:53 AM UTC-7, atd...@gmail.com wrote:
>>
>> Would a md5 hash suffice?
>>
>> I mean, it is probably easy to create collisions, but the source still 
>> needs to compile so...
>>
>> Or an md5 hash and using go/types to make sure that any object escaping 
>> the package boundaries is still present and none other have been added.
>>
>> Any idea?
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How to check that a Go package has not been modified?

[atd...@gmail.com]

Yes, I suppose that clamping the file size, and the requirement that the 
package must pass compilation, even md5 shall do. Thanks to the avalanche 
effect.

On Wednesday, August 3, 2016 at 9:36:34 PM UTC+2, Hotei wrote:
>
> The fact that collisions are possible does not make them "easy to create" 
> especially when you add the compileable requirement.  If you're uneasy 
> about md5 you could always use more bits - like SHA1 used by "git" or 
> SHA256 (or larger) if you're really paranoid.
>
> On Wednesday, August 3, 2016 at 1:14:53 PM UTC-4, atd...@gmail.com wrote:
>>
>> Would a md5 hash suffice?
>>
>> I mean, it is probably easy to create collisions, but the source still 
>> needs to compile so...
>>
>> Or an md5 hash and using go/types to make sure that any object escaping 
>> the package boundaries is still present and none other have been added.
>>
>> Any idea?
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why can't interface value be constant?

[atd...@gmail.com]

Possibily, if you freeze the type of things that can be boxed by the 
interface. But what would it be useful for ?
That would just mean that an interface is constant. Not even that the value 
it wraps can't be changed (because with the current implementation, the 
values an interface wraps need to be addressable).



On Saturday, August 6, 2016 at 9:53:26 AM UTC+2, T L wrote:
>
> Is it possible to make an interface constant if its concrete value type is 
> bool/number/string?
>
> On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Fri, Aug 5, 2016 at 11:21 AM, T L  wrote: 
>> > 
>> > For an interface value, its internal values will never change. 
>> > Are there any problems if golang supports constant interface values? 
>>
>> Pedantically, in Go, constants are untyped by default.  It doesn't 
>> make sense to speak of an untyped interface value.  I would describe 
>> what you are asking for as an immutable variable.  I've often thought 
>> that immutable variables would be useful in Go, but since they have to 
>> be initialized it's not that simple.  For example, io.EOF is 
>> initialized using a function call.  That means that it can't actually 
>> be in read-only memory, and of course it's possible to take it's 
>> address.  How do we prevent it from being changed, without introducing 
>> an immutable qualifier into the type system?  It's a complex problem 
>> for which I have no solution.  And the benefits of an immutable 
>> variable aren't all that high. 
>>
>> Ian 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why can't interface value be constant?

[atd...@gmail.com]

No, I'm saying that the current implementation is two pointers.
The value is addressed by the second pointer. So you cannot really put a 
const in an interface. (thought experiment)

Of course, in the specific case of boxing a value type, that could work. If 
you accept that the *typ never changes throughout the program.

The question is, why a special case, what would you use it for? sync.Pools ?

If it's just for error variables to be constants, maybe it is not worth it. 
What problem does it solve ?

On Saturday, August 6, 2016 at 11:11:24 AM UTC+2, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 4:06:07 PM UTC+8, atd...@gmail.com wrote:
>>
>> Possibily, if you freeze the type of things that can be boxed by the 
>> interface. But what would it be useful for ?
>> That would just mean that an interface is constant. Not even that the 
>> value it wraps can't be changed (because with the current implementation, 
>> the values an interface wraps need to be addressable).
>>
>
> you mean a value should be addressable to let an interface wraps wrap it?
> Not true, "_ = interface{}(1)" is valid in current implementation.
>  
>
>>
>>
>>
>> On Saturday, August 6, 2016 at 9:53:26 AM UTC+2, T L wrote:
>>>
>>> Is it possible to make an interface constant if its concrete value type 
>>> is bool/number/string?
>>>
>>> On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor wrote:
>>>>
>>>> On Fri, Aug 5, 2016 at 11:21 AM, T L  wrote: 
>>>> > 
>>>> > For an interface value, its internal values will never change. 
>>>> > Are there any problems if golang supports constant interface values? 
>>>>
>>>> Pedantically, in Go, constants are untyped by default.  It doesn't 
>>>> make sense to speak of an untyped interface value.  I would describe 
>>>> what you are asking for as an immutable variable.  I've often thought 
>>>> that immutable variables would be useful in Go, but since they have to 
>>>> be initialized it's not that simple.  For example, io.EOF is 
>>>> initialized using a function call.  That means that it can't actually 
>>>> be in read-only memory, and of course it's possible to take it's 
>>>> address.  How do we prevent it from being changed, without introducing 
>>>> an immutable qualifier into the type system?  It's a complex problem 
>>>> for which I have no solution.  And the benefits of an immutable 
>>>> variable aren't all that high. 
>>>>
>>>> Ian 
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why can't interface value be constant?

[atd...@gmail.com]

On Saturday, August 6, 2016 at 11:53:42 AM UTC+2, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 5:45:50 PM UTC+8, atd...@gmail.com wrote:
>>
>> No, I'm saying that the current implementation is two pointers.
>> The value is addressed by the second pointer. So you cannot really put a 
>> const in an interface. (thought experiment)
>>
>> Of course, in the specific case of boxing a value type, that could work. 
>> If you accept that the *typ never changes throughout the program.
>>
>
> for constant intrfaces, the *typ property is not needed. Calling of their 
> methods will confirmed at compile time.
>
 
You need it, the interface cannot be of any type, it would need to be 
initialized with a value of a given type for method dispatch.
The only thing is that the method dispatch would be fixed. (again a thought 
experiment :)

That's similar to sync.Value ( https://golang.org/pkg/sync/atomic/#Value)
 

>  
>
>>
>> The question is, why a special case, what would you use it for? 
>> sync.Pools ?
>>
>> If it's just for error variables to be constants, maybe it is not worth 
>> it. What problem does it solve ?
>>
>
> for safety.
>

What is trhe safety issue? Do you have an example at hand? 

>  
>
>>
>> On Saturday, August 6, 2016 at 11:11:24 AM UTC+2, T L wrote:
>>>
>>>
>>>
>>> On Saturday, August 6, 2016 at 4:06:07 PM UTC+8, atd...@gmail.com wrote:
>>>>
>>>> Possibily, if you freeze the type of things that can be boxed by the 
>>>> interface. But what would it be useful for ?
>>>> That would just mean that an interface is constant. Not even that the 
>>>> value it wraps can't be changed (because with the current implementation, 
>>>> the values an interface wraps need to be addressable).
>>>>
>>>
>>> you mean a value should be addressable to let an interface wraps wrap it?
>>> Not true, "_ = interface{}(1)" is valid in current implementation.
>>>  
>>>
>>>>
>>>>
>>>>
>>>> On Saturday, August 6, 2016 at 9:53:26 AM UTC+2, T L wrote:
>>>>>
>>>>> Is it possible to make an interface constant if its concrete value 
>>>>> type is bool/number/string?
>>>>>
>>>>> On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor 
>>>>> wrote:
>>>>>>
>>>>>> On Fri, Aug 5, 2016 at 11:21 AM, T L  wrote: 
>>>>>> > 
>>>>>> > For an interface value, its internal values will never change. 
>>>>>> > Are there any problems if golang supports constant interface 
>>>>>> values? 
>>>>>>
>>>>>> Pedantically, in Go, constants are untyped by default.  It doesn't 
>>>>>> make sense to speak of an untyped interface value.  I would describe 
>>>>>> what you are asking for as an immutable variable.  I've often thought 
>>>>>> that immutable variables would be useful in Go, but since they have 
>>>>>> to 
>>>>>> be initialized it's not that simple.  For example, io.EOF is 
>>>>>> initialized using a function call.  That means that it can't actually 
>>>>>> be in read-only memory, and of course it's possible to take it's 
>>>>>> address.  How do we prevent it from being changed, without 
>>>>>> introducing 
>>>>>> an immutable qualifier into the type system?  It's a complex problem 
>>>>>> for which I have no solution.  And the benefits of an immutable 
>>>>>> variable aren't all that high. 
>>>>>>
>>>>>> Ian 
>>>>>>
>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why can't interface value be constant?

[atd...@gmail.com]

If you carelessly do anything, you can introduce bugs.

Also note that it is fairly easy in Go to construct immutable "values".

The only thing we do not have is immutable value holders (let in other 
languages) which is a form of static single assignment at the language 
level.
The concept of variable is actually much more "functional" funnily enough, 
but I digress.

Just don't be careless and you should be fine. I have a hard time seeing 
why someone would want to assign a new value to a package level error 
variable.
Maybe you have a specific idea/example in mind?

On Saturday, August 6, 2016 at 1:08:56 PM UTC+2, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 6:04:00 PM UTC+8, atd...@gmail.com wrote:
>>
>>
>>
>> On Saturday, August 6, 2016 at 11:53:42 AM UTC+2, T L wrote:
>>>
>>>
>>>
>>> On Saturday, August 6, 2016 at 5:45:50 PM UTC+8, atd...@gmail.com wrote:
>>>>
>>>> No, I'm saying that the current implementation is two pointers.
>>>> The value is addressed by the second pointer. So you cannot really put 
>>>> a const in an interface. (thought experiment)
>>>>
>>>> Of course, in the specific case of boxing a value type, that could 
>>>> work. If you accept that the *typ never changes throughout the program.
>>>>
>>>
>>> for constant intrfaces, the *typ property is not needed. Calling of 
>>> their methods will confirmed at compile time.
>>>
>>  
>> You need it, the interface cannot be of any type, it would need to be 
>> initialized with a value of a given type for method dispatch.
>> The only thing is that the method dispatch would be fixed. (again a 
>> thought experiment :) 
>>
>
>> That's similar to sync.Value ( https://golang.org/pkg/sync/atomic/#Value)
>>  
>>
>>>  
>>>
>>>>
>>>> The question is, why a special case, what would you use it for? 
>>>> sync.Pools ?
>>>>
>>>> If it's just for error variables to be constants, maybe it is not worth 
>>>> it. What problem does it solve ?
>>>>
>>>
>>> for safety.
>>>
>>
>> What is trhe safety issue? Do you have an example at hand? 
>>
>
> If you carelessly change the value of a global variable in std lib, some 
> hard found bugs will be created.
>  
>
>>  
>>>
>>>>
>>>> On Saturday, August 6, 2016 at 11:11:24 AM UTC+2, T L wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Saturday, August 6, 2016 at 4:06:07 PM UTC+8, atd...@gmail.com 
>>>>> wrote:
>>>>>>
>>>>>> Possibily, if you freeze the type of things that can be boxed by the 
>>>>>> interface. But what would it be useful for ?
>>>>>> That would just mean that an interface is constant. Not even that the 
>>>>>> value it wraps can't be changed (because with the current 
>>>>>> implementation, 
>>>>>> the values an interface wraps need to be addressable).
>>>>>>
>>>>>
>>>>> you mean a value should be addressable to let an interface wraps wrap 
>>>>> it?
>>>>> Not true, "_ = interface{}(1)" is valid in current implementation.
>>>>>  
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Saturday, August 6, 2016 at 9:53:26 AM UTC+2, T L wrote:
>>>>>>>
>>>>>>> Is it possible to make an interface constant if its concrete value 
>>>>>>> type is bool/number/string?
>>>>>>>
>>>>>>> On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Fri, Aug 5, 2016 at 11:21 AM, T L  wrote: 
>>>>>>>> > 
>>>>>>>> > For an interface value, its internal values will never change. 
>>>>>>>> > Are there any problems if golang supports constant interface 
>>>>>>>> values? 
>>>>>>>>
>>>>>>>> Pedantically, in Go, constants are untyped by default.  It doesn't 
>>>>>>>> make sense to speak of an untyped interface value.  I would 
>>>>>>>> describe 
>>>>>>>> what you are asking for as an immutable variable.  I've often 
>>>>>>>> thought 
>>>>>>>> that immutable variables would be useful in Go, but since they have 
>>>>>>>> to 
>>>>>>>> be initialized it's not that simple.  For example, io.EOF is 
>>>>>>>> initialized using a function call.  That means that it can't 
>>>>>>>> actually 
>>>>>>>> be in read-only memory, and of course it's possible to take it's 
>>>>>>>> address.  How do we prevent it from being changed, without 
>>>>>>>> introducing 
>>>>>>>> an immutable qualifier into the type system?  It's a complex 
>>>>>>>> problem 
>>>>>>>> for which I have no solution.  And the benefits of an immutable 
>>>>>>>> variable aren't all that high. 
>>>>>>>>
>>>>>>>> Ian 
>>>>>>>>
>>>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why can't interface value be constant?

[atd...@gmail.com]

On the other hand, I would like to see introduced some variant of slices 
with immutable backing arrays (it will allocate a lot though to modify a 
variable of that type) that would be comparable. That's a whole other topic 
however. slices are a much more delicate concept.

On Saturday, August 6, 2016 at 2:37:40 PM UTC+2, atd...@gmail.com wrote:
>
> If you carelessly do anything, you can introduce bugs.
>
> Also note that it is fairly easy in Go to construct immutable "values".
>
> The only thing we do not have is immutable value holders (let in other 
> languages) which is a form of static single assignment at the language 
> level.
> The concept of variable is actually much more "functional" funnily enough, 
> but I digress.
>
> Just don't be careless and you should be fine. I have a hard time seeing 
> why someone would want to assign a new value to a package level error 
> variable.
> Maybe you have a specific idea/example in mind?
>
> On Saturday, August 6, 2016 at 1:08:56 PM UTC+2, T L wrote:
>>
>>
>>
>> On Saturday, August 6, 2016 at 6:04:00 PM UTC+8, atd...@gmail.com wrote:
>>>
>>>
>>>
>>> On Saturday, August 6, 2016 at 11:53:42 AM UTC+2, T L wrote:
>>>>
>>>>
>>>>
>>>> On Saturday, August 6, 2016 at 5:45:50 PM UTC+8, atd...@gmail.com 
>>>> wrote:
>>>>>
>>>>> No, I'm saying that the current implementation is two pointers.
>>>>> The value is addressed by the second pointer. So you cannot really put 
>>>>> a const in an interface. (thought experiment)
>>>>>
>>>>> Of course, in the specific case of boxing a value type, that could 
>>>>> work. If you accept that the *typ never changes throughout the program.
>>>>>
>>>>
>>>> for constant intrfaces, the *typ property is not needed. Calling of 
>>>> their methods will confirmed at compile time.
>>>>
>>>  
>>> You need it, the interface cannot be of any type, it would need to be 
>>> initialized with a value of a given type for method dispatch.
>>> The only thing is that the method dispatch would be fixed. (again a 
>>> thought experiment :) 
>>>
>>
>>> That's similar to sync.Value ( https://golang.org/pkg/sync/atomic/#Value
>>> )
>>>  
>>>
>>>>  
>>>>
>>>>>
>>>>> The question is, why a special case, what would you use it for? 
>>>>> sync.Pools ?
>>>>>
>>>>> If it's just for error variables to be constants, maybe it is not 
>>>>> worth it. What problem does it solve ?
>>>>>
>>>>
>>>> for safety.
>>>>
>>>
>>> What is trhe safety issue? Do you have an example at hand? 
>>>
>>
>> If you carelessly change the value of a global variable in std lib, some 
>> hard found bugs will be created.
>>  
>>
>>>  
>>>>
>>>>>
>>>>> On Saturday, August 6, 2016 at 11:11:24 AM UTC+2, T L wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Saturday, August 6, 2016 at 4:06:07 PM UTC+8, atd...@gmail.com 
>>>>>> wrote:
>>>>>>>
>>>>>>> Possibily, if you freeze the type of things that can be boxed by the 
>>>>>>> interface. But what would it be useful for ?
>>>>>>> That would just mean that an interface is constant. Not even that 
>>>>>>> the value it wraps can't be changed (because with the current 
>>>>>>> implementation, the values an interface wraps need to be addressable).
>>>>>>>
>>>>>>
>>>>>> you mean a value should be addressable to let an interface wraps wrap 
>>>>>> it?
>>>>>> Not true, "_ = interface{}(1)" is valid in current implementation.
>>>>>>  
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Saturday, August 6, 2016 at 9:53:26 AM UTC+2, T L wrote:
>>>>>>>>
>>>>>>>> Is it possible to make an interface constant if its concrete value 
>>>>>>>> type is bool/number/string?
>>>>>>>>
>>>>>>>> On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor 
>>>>>>>> wro

[go-nuts] map values visibility when the map is populated in a goroutine yet used in another ?

[atd...@gmail.com]

Let's say I have a map in one goroutine that I populate.

Then I make a copy of this map by ranging over its keys/values and pass the 
variable holding the map copy to another goroutine.

Will the values in the copy be necessary visible to the last goroutine?

Is there an happen/before edge between spawning a goroutine and the map 
operations ?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] map values visibility when the map is populated in a goroutine yet used in another ?

[atd...@gmail.com]

Which I should have read more carefully.

Thank you!

On Monday, August 15, 2016 at 5:57:13 PM UTC+2, Jan Mercl wrote:
>
> On Mon, Aug 15, 2016 at 5:28 PM atd...@gmail.com  > wrote:
>
> > Is there an happen/before edge between spawning a goroutine and the map 
> operations ?
>
> Yes: https://golang.org/ref/mem#tmp_5
>
>
> -- 
>
> -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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Quick question about calling Set-Cookie twice in a row

[atd...@gmail.com]

Hello,

As I am writing some tests, I was wondering what should be the correct 
behavior when http.SetCookie is called twice with cookies of a same name 
but different values.

For example, what should a user-agent see as the cookie value and hence, 
what should it return back to the server with the next request?

https://play.golang.org/p/nYDmcFcd8Qj

Many thanks!


-- 
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/80bb88c1-dcad-486f-9448-dae1fada405ao%40googlegroups.com.

[go-nuts] I'd like to write a CSS StyleSheet Parser but...

[atd...@gmail.com]

Hello,

I am currently in need of a css stylesheet parser to retrieve the CSSOM as 
a go datastructure.
(probably in a map[*selector* string]map[*cssproperty* string]interface{})

The existing Go libraries that can be found online are a bit lacking in 
that respect, imho.

But I also have never written any lexer/parser before. Watched Rob's 
youtube video from a while ago which helped in understanding a little bit 
but it's only the lexing part.

So I was wondering, what does the parsing step consist in because the 
examples of codes I've been looking at online so far were a bit confusing 
to me.

I also would like to know if there are ways to create a parser from simply 
inputing the ebnf form (found it for CSS3) somewhere? Becauser I am lazy ;D

Notably, I have never understood what should my output look like after 
parsing... If this is an AST, should I define the Node type structure 
somewhere? What to do?

Bref, I am a total noob on that subject.

Please, help :D
(I also may need to be able to parse the css from an html file afterwards 
but I think there are better libraries that already exist for this case)

-- 
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/1bf065d3-1915-435d-a5bb-c9afc42481dbn%40googlegroups.com.

[go-nuts] GODOC: how to create a reference to another definition in a comment?

[atd...@gmail.com]

Hello,

Just wondering if there is a way to create references to other fields in go 
comments.
If it does not exist, wouldn't it be something valuable, for easier 
navigation in godoc and its new iteration? (I would assume that we would 
have to check comments for broken references on code change)

-- 
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/21bf67f4-4e5f-41fd-b722-dcd0c7bc36d3n%40googlegroups.com.

[go-nuts] Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

Hello,

It' has probably been discussed somewhere but I am curious about what might 
have been the issues when considering an implementation of generics that 
would parameterized packages?

The rationale being that usually, packages have a non-mutable interface for 
the user and are the ompilation unit if I'm not mistaken. So why not just 
relax the interface exposed by a package and allow for package-wide type 
specialization?

In terms of pure parametric polymorphism, having packages with a mutable 
interface in terms of types (via mutation of type aliases for instance) 
would just be the next iteration. It may require a little bit more from the 
build tool but the type checking would not have to change I think. The 
constraints on the parameter would stem implicitly from the code within a 
package in terms of operations used and interfaces being implemented.

I would expect such "parameterized" packages to be rare, non-pervasive if 
not for the simple fact that most parameterized package would mostly be 
able to import other generic packages since they would be defined with 
abstract types. The compiler may still want to insure that the constraints 
make sense throughout the dependency tree  of generic imports incrementally 
but I don't think that that would be a huge problem.

I think that it could be something orthogonal to the design of type 
constraintd, notably type Lists, that are anyway highly desirable imo but 
more so to constrain interfaces to a finite set of types ( as a way to have 
union types, enums, sumtypes or whatnot).



-- 
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/4a7b128c-abaf-4399-a19b-657f9cf1443bn%40googlegroups.com.

[go-nuts] Re: GODOC: how to create a reference to another definition in a comment?

[atd...@gmail.com]

For instance,

// Node returns a tree node. The value for the node type are specified 
// in the definition of @href="NodeType"
type Node struct{...}

// NodeType defines the types of Node values
// They can be ...etc
type NodeType int


clicking on the ref would allow to make a jump to the relevant part of the 
documentation for instance.
Is there any facility already for this?
On Saturday, January 16, 2021 at 2:20:33 PM UTC+1 atd...@gmail.com wrote:

> Hello,
>
> Just wondering if there is a way to create references to other fields in 
> go comments.
> If it does not exist, wouldn't it be something valuable, for easier 
> navigation in godoc and its new iteration? (I would assume that we would 
> have to check comments for broken references on code change)
>
>

-- 
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/21019787-a59c-4cde-8d9c-8ed9821eefaen%40googlegroups.com.

[go-nuts] Re: Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

It does mention it but I fail to see the problem specifically. I am curious 
about anything that would make it a proposal-killer in terms of design for 
Go.
Also, the distinction I see is that it would not be the same instantiation 
of the same package as much as the creation of new packages ( the package 
names should be parameterized too depending on the input)
As such, packages could be cached and reused for the same input parameters.
 
Having different packages for different kinds seems to be a good separation 
of concerns to me. Quite the opposite from mixing package boundaries with 
types, I think it's rather the opposite. (the oppsoite being to allow 
generic functions spreading across package boundaries)  
Besides, that's exactly what would happen if we had to do it by hand as of 
today or via code-generation. Hence, we get type specialization trivially. 

 
For instance, if we take the List counter-example, I understand that higher 
kind polymorphism allow to have only one function definition, albeit 
parameterized, but it's more complex to write (constraints) and it may 
allow a pervasive use of  generics that may not be conducive to simple go 
code.
(Namely, the introduction of the functional patterns such as 
map/transform/reduce. (which is nothing but an abstraction... nice for 
people who appreciate it but not necessarily as a generic function imo))

The rest of use-cases for generics could be handled with interfaces and/or 
the introduction of type-lists, enabling union/sumtypes, essentially 
augmenting the concept of interface types. 


On Wednesday, January 20, 2021 at 6:21:10 PM UTC+1 jake...@gmail.com wrote:

> If I understand correctly, this question is specifically addressed by the 
> design draft: 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages
>
> On Wednesday, January 20, 2021 at 10:22:19 AM UTC-5 atd...@gmail.com 
> wrote:
>
>> Hello,
>>
>> It' has probably been discussed somewhere but I am curious about what 
>> might have been the issues when considering an implementation of generics 
>> that would parameterized packages?
>>
>> The rationale being that usually, packages have a non-mutable interface 
>> for the user and are the ompilation unit if I'm not mistaken. So why not 
>> just relax the interface exposed by a package and allow for package-wide 
>> type specialization?
>>
>> In terms of pure parametric polymorphism, having packages with a mutable 
>> interface in terms of types (via mutation of type aliases for instance) 
>> would just be the next iteration. It may require a little bit more from the 
>> build tool but the type checking would not have to change I think. The 
>> constraints on the parameter would stem implicitly from the code within a 
>> package in terms of operations used and interfaces being implemented.
>>
>> I would expect such "parameterized" packages to be rare, non-pervasive if 
>> not for the simple fact that most parameterized package would mostly be 
>> able to import other generic packages since they would be defined with 
>> abstract types. The compiler may still want to insure that the constraints 
>> make sense throughout the dependency tree  of generic imports incrementally 
>> but I don't think that that would be a huge problem.
>>
>> I think that it could be something orthogonal to the design of type 
>> constraintd, notably type Lists, that are anyway highly desirable imo but 
>> more so to constrain interfaces to a finite set of types ( as a way to have 
>> union types, enums, sumtypes or whatnot).
>>
>>
>>
>>

-- 
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/7ba98154-ecee-4657-9985-ce21a80c68c2n%40googlegroups.com.

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

It didn't seem to me like proposal-killers enoguh so much so that they 
might not have liked some of the design choices they entailed.

The proble with the current running proposal is that it is a generalization 
fo what the compiler does. It definitely  permits the spread of generic 
functions across package boundaries since they can be exported. Only that 
the type inference allows to not have to express the constraints in most 
cases. This is still a complication.

What I'd like to know is what are the complexities in a 
package-parametrization. Indeed it would require additional syntax for 
package import, there would still be a problem with zero-values return. But 
it could be so much more simple other than that. 

The alternative is doing what the compiler does and dealing with constraint 
on kinds. Which is a bit more complex.

As far as deriving constraints from code, I think that it's actually 
completely different at the package level than doing it at a higher 
granularity ( functions) because a function is not a compilation unit.
It is similar to essentialy replacing a name and building the package.
At the function level, I would presume that  more information about the 
flow of data would be required.

As a note, I think that with the first iteration of type aliases, people 
had started experimenting with such parameterization(I think in the image 
package). Seems a bit more intuitive.
Obviously, the difference is that packages are uniquely identified by their 
names which is why, the names have to be internally parameterized as well.

I think that dividing the design space for parametricity into simple code 
parametrization at the package level and type list interfaces on the other 
hand could be clearer and easier to handle but I'd like to know what are 
the pain points.


On Wednesday, January 20, 2021 at 8:22:07 PM UTC+1 
axel.wa...@googlemail.com wrote:

> The proposal-killers are mentioned - it is awkward for different 
> instantiations of the same package to interact and there is no reason to 
> believe generic usecases will delineate neatly into packages. It sounds 
> like you do not agree that those are proposal-killers. And of course, you 
> are welcome to write down your own design and maybe you even see something 
> they didn't see. But you should be prepared that ultimately, in a "agree to 
> disagree" situation, if the Go team feels it is awkward, their opinion will 
> be what tips the scales.
>
> On Wed, Jan 20, 2021 at 7:09 PM atd...@gmail.com  wrote:
>
>> Also, the distinction I see is that it would not be the same 
>> instantiation of the same package as much as the creation of new packages ( 
>> the package names should be parameterized too depending on the input)
>>
>
> Just to point out the obvious, that this means you still have to make up a 
> syntax for type-parameters and instantiations. So, this is not a simple 
> matter of importing a regular package.
>
> Having different packages for different kinds seems to be a good 
>> separation of concerns to me. Quite the opposite from mixing package 
>> boundaries with types, I think it's rather the opposite. (the oppsoite 
>> being to allow generic functions spreading across package boundaries)  
>>
>
> Generic functions do not spread across package boundaries. Every generic 
> function and every generic type will still live in a single package.
>  
>
>> it's more complex to write (constraints)
>>
>
> FTR, the way to express constraints is largely independent on whether you 
> constrain types on a per-function/type or per-package level.
> For example, you suggested constraints should be derived implicitly based 
> on the operations used in the package. But you can do that with generic 
> functions too. For example, a previous incarnation of the generics design 
> <https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md> 
> would have allowed you to specify constraints by writing a function body 
> using all operations you need. In particular, you could've used the 
> function body itself as a contract. So if you take that design and just 
> declare that the contract of a generic function is *implicitly* its 
> function body, you'd get your idea of "constraint-less generics", while 
> operating entirely on a per-function level.
>
> That previous incarnation was abandoned though, because it turns out that 
> implicitly deriving constraints from code is just surprisingly complicated, 
> opens up more questions than it answers and - in my opinion at least - just 
> generally a very bad idea. So, I'm not too optimistic about a new proposal, 
> that tries to go back to that approach.
>
> In any case. As I said, my goal isn't really to convince y

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

I have been asking because the List of List example seemed a bit contrieved 
to me. I have seen maps of linked lists or slice of slices for math stuff 
but rarely lists of lists.(probably because of the time complexity)

But yes, composing the parametrization is probably not something that 
should be possible. Would have to have  package List[int] fully created 
beforehand via code generation. No recursive instantiation.

I think I understand the worry more clearly. Paramaeterized packages make 
the definition of Higher Kinded operations more difficult. The Transform 
function which operates on Lists would be one example.

This could also be a feature to have some things more difficult to do. I 
have no idea on this, I think it would require data on the kind of code 
that is needed the most in the wild.
Not sure that the most powerful generics facilities are required. I think 
that the current set of constraints of what is expressible via current Go 
code is also why it is successful. Namely the small set of identifiable, 
common idioms.
If Higher Kinded type of functions are easily created, one could fear that 
there wiould be more code styles within the Go ecosystem.
But anyway, it needs data across codebases to see what is required. (I know 
that scientific code, ML code will be wildly different for instance)
But yes, I guess would tend to agree with Arnaud.

Thanks for the answers! :)

On Wednesday, January 20, 2021 at 9:37:11 PM UTC+1 Ian Lance Taylor wrote:

> On Wed, Jan 20, 2021 at 11:42 AM atd...@gmail.com  
> wrote:
> >
> >
> > It didn't seem to me like proposal-killers enoguh so much so that they 
> might not have liked some of the design choices they entailed.
> >
> > The proble with the current running proposal is that it is a 
> generalization fo what the compiler does. It definitely permits the spread 
> of generic functions across package boundaries since they can be exported. 
> Only that the type inference allows to not have to express the constraints 
> in most cases. This is still a complication.
> >
> > What I'd like to know is what are the complexities in a 
> package-parametrization. Indeed it would require additional syntax for 
> package import, there would still be a problem with zero-values return. But 
> it could be so much more simple other than that.
> >
> > The alternative is doing what the compiler does and dealing with 
> constraint on kinds. Which is a bit more complex.
> >
> > As far as deriving constraints from code, I think that it's actually 
> completely different at the package level than doing it at a higher 
> granularity ( functions) because a function is not a compilation unit.
> > It is similar to essentialy replacing a name and building the package.
> > At the function level, I would presume that more information about the 
> flow of data would be required.
> >
> > As a note, I think that with the first iteration of type aliases, people 
> had started experimenting with such parameterization(I think in the image 
> package). Seems a bit more intuitive.
> > Obviously, the difference is that packages are uniquely identified by 
> their names which is why, the names have to be internally parameterized as 
> well.
> >
> > I think that dividing the design space for parametricity into simple 
> code parametrization at the package level and type list interfaces on the 
> other hand could be clearer and easier to handle but I'd like to know what 
> are the pain points.
>
>
> I think Axel has expressed the pain points pretty well.
>
> You've got a List package that lets you manage linked lists of some
> type. So you write
>
> import listint "list[int]"
>
> and then you can write lst := listint.New(); lst.Push(1). Or
> something like that.
>
> Now you want a list of lists of int. How do you write that?
>
> import listint "list[int]"
> import listlistint "list[listint.List]"
>
> ?
>
> That is not how imports work in Go. Now import has changed from
> "import a package" to "instantiate an imported package". Those are
> pretty different operations.
>
> Also look at 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#list-transform
> and think about how to implement that using generic packages.
>
> More generally, there just isn't any clear reason to believe that
> generic types and functions naturally map to package boundaries. It's
> easy to think up cases where I would want an unexported generic
> function. If only packages can be generic, then I have to create a
> new internal package just to represent that function. That seems
> tedious.
>
> You have asked a couple of 

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

It's not about bad or useless, the same way Go is not useless because of 
its current set of constraints.
It's about implementing which you can derive the most value of(also in 
terms of simplicity, code-sharing etc.)

Meta-programming is all-encompassing but it's problematic. Give someone a 
hammer and everything looks like nails.

On Wednesday, January 20, 2021 at 10:35:43 PM UTC+1 
axel.wa...@googlemail.com wrote:

> Personally, I feel that "let's reduce utility while keeping complexity 
> constant" is a questionable approach, if you feel that generics don't 
> provide enough value to justify their complexity. I feel that *if* we 
> introduce generics, we should make sure they actually pay for their cost. 
> I'd much rather have no generics at all, than a bad and useless 
> implementation of them.
>
> On Wed, Jan 20, 2021 at 10:19 PM atd...@gmail.com  
> wrote:
>
>> I have been asking because the List of List example seemed a bit 
>> contrieved to me. I have seen maps of linked lists or slice of slices for 
>> math stuff but rarely lists of lists.(probably because of the time 
>> complexity)
>>
>> But yes, composing the parametrization is probably not something that 
>> should be possible. Would have to have  package List[int] fully created 
>> beforehand via code generation. No recursive instantiation.
>>
>> I think I understand the worry more clearly. Paramaeterized packages make 
>> the definition of Higher Kinded operations more difficult. The Transform 
>> function which operates on Lists would be one example.
>>
>> This could also be a feature to have some things more difficult to do. I 
>> have no idea on this, I think it would require data on the kind of code 
>> that is needed the most in the wild.
>> Not sure that the most powerful generics facilities are required. I think 
>> that the current set of constraints of what is expressible via current Go 
>> code is also why it is successful. Namely the small set of identifiable, 
>> common idioms.
>> If Higher Kinded type of functions are easily created, one could fear 
>> that there wiould be more code styles within the Go ecosystem.
>> But anyway, it needs data across codebases to see what is required. (I 
>> know that scientific code, ML code will be wildly different for instance)
>> But yes, I guess would tend to agree with Arnaud.
>>
>> Thanks for the answers! :)
>>
>> On Wednesday, January 20, 2021 at 9:37:11 PM UTC+1 Ian Lance Taylor wrote:
>>
>>> On Wed, Jan 20, 2021 at 11:42 AM atd...@gmail.com  
>>> wrote: 
>>> > 
>>> > 
>>> > It didn't seem to me like proposal-killers enoguh so much so that they 
>>> might not have liked some of the design choices they entailed. 
>>> > 
>>> > The proble with the current running proposal is that it is a 
>>> generalization fo what the compiler does. It definitely permits the spread 
>>> of generic functions across package boundaries since they can be exported. 
>>> Only that the type inference allows to not have to express the constraints 
>>> in most cases. This is still a complication. 
>>> > 
>>> > What I'd like to know is what are the complexities in a 
>>> package-parametrization. Indeed it would require additional syntax for 
>>> package import, there would still be a problem with zero-values return. But 
>>> it could be so much more simple other than that. 
>>> > 
>>> > The alternative is doing what the compiler does and dealing with 
>>> constraint on kinds. Which is a bit more complex. 
>>> > 
>>> > As far as deriving constraints from code, I think that it's actually 
>>> completely different at the package level than doing it at a higher 
>>> granularity ( functions) because a function is not a compilation unit. 
>>> > It is similar to essentialy replacing a name and building the package. 
>>> > At the function level, I would presume that more information about the 
>>> flow of data would be required. 
>>> > 
>>> > As a note, I think that with the first iteration of type aliases, 
>>> people had started experimenting with such parameterization(I think in the 
>>> image package). Seems a bit more intuitive. 
>>> > Obviously, the difference is that packages are uniquely identified by 
>>> their names which is why, the names have to be internally parameterized as 
>>> well. 
>>> > 
>>> > I think that dividing the design space for parametricity int

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

Oh, I know it does, as mentioned above. Typically to emulate matrices.

My point was that it is still different from a linked list of linked 
lists.If not time complexity, data locality etc. May be useful for some 
type of very large graph datastructures, I wouldn,'t know since I haven't 
encountered this use case yet.
If many other people have felt the need for list of lists then I would be 
enlightened.

Also, just pointing out that having higher-order functions easily created 
at compile time for generic code is nice but we also have interfaces which 
could alleviate part of the issue.
In the end, I am sure you have more data points than I have, my questions 
have been mostly answered, I'll leave the rest in your care.

Cheers,

On Thursday, January 21, 2021 at 1:09:23 AM UTC+1 Ian Lance Taylor wrote:

> On Wed, Jan 20, 2021 at 1:19 PM atd...@gmail.com  wrote:
> >
> > I have been asking because the List of List example seemed a bit 
> contrieved to me. I have seen maps of linked lists or slice of slices for 
> math stuff but rarely lists of lists.(probably because of the time 
> complexity)
>
> We will have to disagree on that. A list of lists of int is no more
> contrived than a type like [][]byte, which is a type that appears at
> least 50 times in the Go standard library.
>
> Ian
>

-- 
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/d51f545b-59af-41dd-bf38-b4a7afe65714n%40googlegroups.com.

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

I know but in the case of map, it's a built-in. We have easily higher order 
functions for that that can be defined.

Where there is a problem is defining higher order functions for generic 
user-defined containers... I think that it is going a bit too far in the 
parametrization. It may happen and be somewhat useful, but I don't think 
that the design should be optimized for it unless pervasive.

I leave the Set datastructure out because the implementations may vary too 
much and I do not have any data points on this. But the question is, are 
people more likely to use maps of sets or sets of sets...?

On Thursday, January 21, 2021 at 1:39:41 AM UTC+1 axel.wa...@googlemail.com 
wrote:

> FTR, the same argument that applies to `List(List(int))` also applies to 
> `Set(Set(int))` and `Map(Key1, Map(Key2, Val))`, neither of which suffers 
> from algorithmic complexity issues and both of which I have used in the 
> past in real code.
>
> On Thu, Jan 21, 2021 at 1:35 AM atd...@gmail.com  wrote:
>
>> Oh, I know it does, as mentioned above. Typically to emulate matrices.
>>
>> My point was that it is still different from a linked list of linked 
>> lists.If not time complexity, data locality etc. May be useful for some 
>> type of very large graph datastructures, I wouldn,'t know since I haven't 
>> encountered this use case yet.
>> If many other people have felt the need for list of lists then I would be 
>> enlightened.
>>
>> Also, just pointing out that having higher-order functions easily created 
>> at compile time for generic code is nice but we also have interfaces which 
>> could alleviate part of the issue.
>> In the end, I am sure you have more data points than I have, my questions 
>> have been mostly answered, I'll leave the rest in your care.
>>
>> Cheers,
>>
>> On Thursday, January 21, 2021 at 1:09:23 AM UTC+1 Ian Lance Taylor wrote:
>>
>>> On Wed, Jan 20, 2021 at 1:19 PM atd...@gmail.com  
>>> wrote: 
>>> > 
>>> > I have been asking because the List of List example seemed a bit 
>>> contrieved to me. I have seen maps of linked lists or slice of slices for 
>>> math stuff but rarely lists of lists.(probably because of the time 
>>> complexity) 
>>>
>>> We will have to disagree on that. A list of lists of int is no more 
>>> contrived than a type like [][]byte, which is a type that appears at 
>>> least 50 times in the Go standard library. 
>>>
>>> Ian 
>>>
>> -- 
>>
> 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/d51f545b-59af-41dd-bf38-b4a7afe65714n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/d51f545b-59af-41dd-bf38-b4a7afe65714n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f0b9eab5-cbc3-4d4c-a273-65d32bbdb1f2n%40googlegroups.com.

Re: [go-nuts] Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

Looking briefly, seems interesting but slightly different. It seems that 
the intent described in the paper is to endorse full blown functions as a 
replacement to import statements.

It is useful insofar that it could rationalize the use of build constraints 
in Go. But it is too expressive in that it may obscure which packages are 
actually imported amongst other things.

For instance, it allows to branch and decide on different implementations 
for hashmaps depending on a size parameter. This is a bit different from 
what I had in mind as I think that generic packages should be encapsulated 
and 
would simply expose a simple interface to some of their internal state 
(mostlly allowing to replace type names).

The consequences would be a bit different Ibelieve.

That is another example where I think, too much power is granted to the 
programmer, in the sake of generalization. Now, the evaluation of import 
constraints may slow down the build of large programs arbitrarily,
and, as you mentioned, it requires package to be virtualized (because their 
definition/instantiation is not static anymore) which I don't think is 
desirable.

The advantage of doing things a bit more simply is that we could decide to 
save parameterized packages to files via code generation if required. The 
constraints are static.

(I really appreciate everyday that Go is not "over-engineered")

On Thursday, January 21, 2021 at 2:54:19 PM UTC+1 jesper.lou...@gmail.com 
wrote:

> On Wed, Jan 20, 2021 at 4:22 PM atd...@gmail.com  wrote:
>
>> It' has probably been discussed somewhere but I am curious about what 
>> might have been the issues when considering an implementation of generics 
>> that would parameterized packages?
>>
>>
> You can take a look at Standard ML / Ocaml "functors" if you want to see 
> an exploration of what it entails as a consequence. It's a completely 
> different approach, and often you'd find you need to improve the 
> module/package system of the language in order to make it feel fluid for a 
> programmer. For Go, it would require quite some language extension before 
> it would be viable (or rather, that is my hunch). One particular important 
> point is that you tend to end up with a "stratification" of sorts. The 
> module system becomes a language of its own, on top of a core language and 
> they don't mix. The stratification isn't required though, as shown by 
> Andreas Rossberg in his 1ML paper. In Go terms, you remove structs, and a 
> struct is a package containing a "var" section. Now, parameterization of 
> packages becomes parametrization of interfaces/structs as a result. What 
> Rossberg shows is that you can create a language out of this idea, and said 
> language "works" insofar it's possible to give it a sensible semantics.
>
> Note: for this to work, you really want packages to be nestable inside 
> packages. And you also want to decouple packages entirely from the file 
> system, by which time you have a language entirely different from Go.
>
>

-- 
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/920510e8-36a4-4f86-a7c5-ffc9adb313afn%40googlegroups.com.

[go-nuts] sycall/js : does it require build tags? if so whihc ones?

[atd...@gmail.com]

Hello,

I'm using atom and am trying to import the syscall/js package.

My issue is that I do not know which build constraints I should specify for 
the static analysers to process the code.
I'm getting a message as such:
js.go:7:3: build constraints exclude all Go files in 
/usr/local/go/src/syscall/js

I am using atom with go-plus.

Any suggestions?

-- 
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/ea46955d-23d1-4ad2-be3d-f2de19767251n%40googlegroups.com.

Re: [go-nuts] Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

Just coming back to this quickly, although it is unlikely to change 
anything at this stage, but, re. a transform function, instead of using 
parametric polymorphism, I think it is possible to do it with interface 
arguments and to a greater extent, type lists interface arguments if we 
have access to these in the future..

It would require to have the transform function in its own package. I don't 
expect it to be a big problem as I do not think that a transform function 
require full-parametricity: to transofrm a list of U elements into anoter 
list of V elements,
I would tend to think that U and V need to be known in advance. A purely 
generic transformation seems a bit of a red herring to me.

So, not so sure that it would be a counter argument to package 
parametrization.

However, the only example I may conceive to be a bit annoying is providing 
a "seemingly" single generic Max function, If for instance, we want the 
math package to be a regular package that also expose a few generic 
functions.
I would tend to think that this is where it would be difficult to bind the 
type of the argument with the type of the return value with only type lists.

With a package parametrization, we would have to introduce a math/generic 
package and have something like:

 import  (
 mint math/generic [type T= int]
 mfloat math/generic [type T=float]

If we have code that requires Max on ints and floats within a same package, 
that would make people have to use 2 different max functions, (just like we 
do these days anyway)

mint.Max(2,3)
mfloat.Max(2.0,3.0)

No opinion on this. I don't think it would bother me but...

Am I missing something?

On Thursday, January 21, 2021 at 4:37:17 PM UTC+1 atd...@gmail.com wrote:

> Looking briefly, seems interesting but slightly different. It seems that 
> the intent described in the paper is to endorse full blown functions as a 
> replacement to import statements.
>
> It is useful insofar that it could rationalize the use of build 
> constraints in Go. But it is too expressive in that it may obscure which 
> packages are actually imported amongst other things.
>
> For instance, it allows to branch and decide on different implementations 
> for hashmaps depending on a size parameter. This is a bit different from 
> what I had in mind as I think that generic packages should be encapsulated 
> and 
> would simply expose a simple interface to some of their internal state 
> (mostlly allowing to replace type names).
>
> The consequences would be a bit different Ibelieve.
>
> That is another example where I think, too much power is granted to the 
> programmer, in the sake of generalization. Now, the evaluation of import 
> constraints may slow down the build of large programs arbitrarily,
> and, as you mentioned, it requires package to be virtualized (because 
> their definition/instantiation is not static anymore) which I don't think 
> is desirable.
>
> The advantage of doing things a bit more simply is that we could decide to 
> save parameterized packages to files via code generation if required. The 
> constraints are static.
>
> (I really appreciate everyday that Go is not "over-engineered")
>
> On Thursday, January 21, 2021 at 2:54:19 PM UTC+1 jesper.lou...@gmail.com 
> wrote:
>
>> On Wed, Jan 20, 2021 at 4:22 PM atd...@gmail.com  
>> wrote:
>>
>>> It' has probably been discussed somewhere but I am curious about what 
>>> might have been the issues when considering an implementation of generics 
>>> that would parameterized packages?
>>>
>>>
>> You can take a look at Standard ML / Ocaml "functors" if you want to see 
>> an exploration of what it entails as a consequence. It's a completely 
>> different approach, and often you'd find you need to improve the 
>> module/package system of the language in order to make it feel fluid for a 
>> programmer. For Go, it would require quite some language extension before 
>> it would be viable (or rather, that is my hunch). One particular important 
>> point is that you tend to end up with a "stratification" of sorts. The 
>> module system becomes a language of its own, on top of a core language and 
>> they don't mix. The stratification isn't required though, as shown by 
>> Andreas Rossberg in his 1ML paper. In Go terms, you remove structs, and a 
>> struct is a package containing a "var" section. Now, parameterization of 
>> packages becomes parametrization of interfaces/structs as a result. What 
>> Rossberg shows is that you can create a language out of this idea, and said 
>> language "works" insofar it's possible to give it a sensible semantics.
>>
>> Note: for this

Re: [go-nuts] Quick question about the generics alternatives that have been considered

[atd...@gmail.com]

Forget about it. Does not work. Can't avoid having to constrain types. An 
algorithm for value types would not be so easily usable with pointer types, 
at the very least because of nil checks.

And, although it might not be a problem, if we ever have type list 
interfaces, or even simple multi-parametered packages, there will be a need 
to split packages into a combination of subpackages based on arities etc.
Otherwise, we could have two func(int) defined by different packages 
(package List[T= int, U= float] and package List[T=int, U= string]
Probably solvable but anyway...

On Thursday, February 4, 2021 at 2:54:09 AM UTC+1 atd...@gmail.com wrote:

> Just coming back to this quickly, although it is unlikely to change 
> anything at this stage, but, re. a transform function, instead of using 
> parametric polymorphism, I think it is possible to do it with interface 
> arguments and to a greater extent, type lists interface arguments if we 
> have access to these in the future..
>
> It would require to have the transform function in its own package. I 
> don't expect it to be a big problem as I do not think that a transform 
> function require full-parametricity: to transofrm a list of U elements into 
> anoter list of V elements,
> I would tend to think that U and V need to be known in advance. A purely 
> generic transformation seems a bit of a red herring to me.
>
> So, not so sure that it would be a counter argument to package 
> parametrization.
>
> However, the only example I may conceive to be a bit annoying is providing 
> a "seemingly" single generic Max function, If for instance, we want the 
> math package to be a regular package that also expose a few generic 
> functions.
> I would tend to think that this is where it would be difficult to bind the 
> type of the argument with the type of the return value with only type lists.
>
> With a package parametrization, we would have to introduce a math/generic 
> package and have something like:
>
>  import  (
>  mint math/generic [type T= int]
>  mfloat math/generic [type T=float]
>
> If we have code that requires Max on ints and floats within a same 
> package, that would make people have to use 2 different max functions, 
> (just like we do these days anyway)
>
> mint.Max(2,3)
> mfloat.Max(2.0,3.0)
>
> No opinion on this. I don't think it would bother me but...
>
> Am I missing something?
>
> On Thursday, January 21, 2021 at 4:37:17 PM UTC+1 atd...@gmail.com wrote:
>
>> Looking briefly, seems interesting but slightly different. It seems that 
>> the intent described in the paper is to endorse full blown functions as a 
>> replacement to import statements.
>>
>> It is useful insofar that it could rationalize the use of build 
>> constraints in Go. But it is too expressive in that it may obscure which 
>> packages are actually imported amongst other things.
>>
>> For instance, it allows to branch and decide on different implementations 
>> for hashmaps depending on a size parameter. This is a bit different from 
>> what I had in mind as I think that generic packages should be encapsulated 
>> and 
>> would simply expose a simple interface to some of their internal state 
>> (mostlly allowing to replace type names).
>>
>> The consequences would be a bit different Ibelieve.
>>
>> That is another example where I think, too much power is granted to the 
>> programmer, in the sake of generalization. Now, the evaluation of import 
>> constraints may slow down the build of large programs arbitrarily,
>> and, as you mentioned, it requires package to be virtualized (because 
>> their definition/instantiation is not static anymore) which I don't think 
>> is desirable.
>>
>> The advantage of doing things a bit more simply is that we could decide 
>> to save parameterized packages to files via code generation if required. 
>> The constraints are static.
>>
>> (I really appreciate everyday that Go is not "over-engineered")
>>
>> On Thursday, January 21, 2021 at 2:54:19 PM UTC+1 jesper.lou...@gmail.com 
>> wrote:
>>
>>> On Wed, Jan 20, 2021 at 4:22 PM atd...@gmail.com  
>>> wrote:
>>>
>>>> It' has probably been discussed somewhere but I am curious about what 
>>>> might have been the issues when considering an implementation of generics 
>>>> that would parameterized packages?
>>>>
>>>>
>>> You can take a look at Standard ML / Ocaml "functors" if you want to see 
>>> an exploration of what it entails as a consequence. It's a completely 
>>> different approach, 

[go-nuts] encoding/html package to generate html markup programmatically

[atd...@gmail.com]

Hi,

I am currently thinking about implementing SSR for a Go client-side 
framework.
Not only that but I would like to be able to create static html from the 
same code I use to create dynamic  wasm-based webapps.

I was trying to find a package that would enable me to generate an html 
document but seems like none exists.

Do you think it is possible to use encoding/xml to create an xhtml document?


That would allow me to create something like MarkupPy that would replace js 
DOM created element by html element.

-- 
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/1c6efb34-4028-433e-b67c-5774ea014e52n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[atd...@gmail.com]

I am in favor of the proposal but I think that accounting for popularity 
votes is not a good measure of things.
A lot of people are at various stages of their technical journey in 
computer science and engineering and there has to be a weight given to the 
more technical opinions that is not reflected in the github upvote/downvote 
system.
At one point, everyone would have upvoted that the earth was flat.

Just a note in passing :)

On Monday, March 15, 2021 at 11:03:50 PM UTC+1 Ian Lance Taylor wrote:

> On Mon, Mar 15, 2021 at 5:08 AM Space A.  wrote:
> >
> > > For example, the multiple proposals that flowed out of
> > 
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
> .
> > None of them have been adopted.
> >
> > I remember what was happening to "try" error handling proposal. It was 
> withdrawn only because of active resistance by the community.
> >
> > And what's happened to a new "generics" proposal, it also got a lot of 
> critics but was "accepted" in less than a month after formal publication on 
> github. As Russ said "No change in consensus". What does it mean? Who are 
> these people who can change the consensus? How was it measured? A few days 
> after Russ locked it, so nobody can even say a word against it if they 
> wanted. So it looks very much that company management learned from "try" 
> proposal.
>
> The design draft was put up for discussion for months before it became
> a formal proposal. It was not new.
>
> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
> up and 123 thumbs down (and ten "confused"). Yes, there were critics.
> But I think it is fair to say that the proposal has far more
> supporters than critics.
>
> The "no change in consensus" comment refers to the discussion after
> the proposal was moved to "likely accept" status:
> https://github.com/golang/go/issues/43651#issuecomment-772744198.
> After it was marked as "likely accept", there was no change to the
> consensus that it should be accepted. (Note that the "likely accept"
> comment got 60 thumbs up and 0 thumbs down (and one "confused").)
>
> None of this is anything like the "try" proposal
> (https://golang.org/issue/32437), which had 318 thumbs up and 794
> thumbs down (and 132 "confused").
>
> Ian
>

-- 
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/932a39b7-be1b-4c15-b7c8-f99fce730b0en%40googlegroups.com.

[go-nuts] Re: encoding/html package to generate html markup programmatically

[atd...@gmail.com]

Oh, you might be my savior ! :)
I starred it and am going to look into it. Looks quite promising!

On Monday, March 15, 2021 at 6:52:58 PM UTC+1 michael...@gmail.com wrote:

> goht <https://github.com/Michael-F-Ellis/goht> might be what you're 
> looking for.
>
> On Sunday, March 14, 2021 at 7:36:52 PM UTC-4 atd...@gmail.com wrote:
>
>> Hi,
>>
>> I am currently thinking about implementing SSR for a Go client-side 
>> framework.
>> Not only that but I would like to be able to create static html from the 
>> same code I use to create dynamic  wasm-based webapps.
>>
>> I was trying to find a package that would enable me to generate an html 
>> document but seems like none exists.
>>
>> Do you think it is possible to use encoding/xml to create an xhtml 
>> document?
>>
>>
>> That would allow me to create something like MarkupPy that would replace 
>> js DOM created element by html element.
>>
>>

-- 
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/c74ad520-5e62-4697-b06a-e77272ac3365n%40googlegroups.com.

[go-nuts] Type parameters syntax... Can it be improved?

[atd...@gmail.com]

Quick question...

Why do we need brackets to define a parametered function, struct etc...?

Why not change Go kinds to accept either a type (would produce a regular, 
function, structs, etc) or a new type parameter object that would implement 
the constraints (would produce a generic function definition)

for instance,

type parameter T

// [...]  some way to add constraint to T

func Max(v T) T{...} 

What are the brackets for? Just an idea.

-- 
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/f7f85bc8-667e-4d75-81e2-76bb70828fcbn%40googlegroups.com.

Re: [go-nuts] Type parameters syntax... Can it be improved?

[atd...@gmail.com]

Since, we also know the type of v, It would be infered from it.

There is no variance, no dependent type... Meaning that the type of a Go 
variable does not change. 
So the constraints do not change midway through the program, including type 
names/definitions.

It does however require to have something that resemble a type definition 
beforehand.
A type parameter definition.


On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote:

> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com  wrote:
> >
> > Quick question...
> >
> > Why do we need brackets to define a parametered function, struct etc...?
> >
> > Why not change Go kinds to accept either a type (would produce a 
> regular, function, structs, etc) or a new type parameter object that would 
> implement the constraints (would produce a generic function definition)
> >
> > for instance,
> >
> > type parameter T
> >
> > // [...] some way to add constraint to T
> >
> > func Max(v T) T{...}
> >
> > What are the brackets for? Just an idea.
>
> Each call to Max can use a different value for T. We can call
> Max[int] and Max[string]. How would we do that with this notation?
>
> A type parameter really is a parameter to the function. Making it
> syntactically similar to other non-type parameters seems like a good
> idea to me.
>
> Ian
>

-- 
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/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%40googlegroups.com.

Re: [go-nuts] Type parameters syntax... Can it be improved?

[atd...@gmail.com]

Mmmh, :/ depends. What is the type of IntMin for the compiler in your 
example? The same as Min?

If not, it is basically defining a regular function out of a generic 
function definition.
So it is merely about constraining the type parameter further to be of 
specific type int.

A simple closure would be a sensible way to deal with it easily. In 
general, one would define a general closure function with new type 
parameters that have aditional constraints.

Trying to see type parameters more like concrete types and interface types, 
just with different constraints enforced at compile-time than those of 
types and interface types.
Could make brackets redundant.
On Tuesday, March 23, 2021 at 11:22:51 PM UTC+1 Ian Lance Taylor wrote:

> On Tue, Mar 23, 2021 at 3:19 PM atd...@gmail.com  wrote:
> >
> > Since, we also know the type of v, It would be infered from it.
> >
> > There is no variance, no dependent type... Meaning that the type of a Go 
> variable does not change.
> > So the constraints do not change midway through the program, including 
> type names/definitions.
> >
> > It does however require to have something that resemble a type 
> definition beforehand.
> > A type parameter definition.
>
> In some cases it can be inferred. But what about cases where it
> can't? And what if I want to write
>
> // IntMin is a function with type func(int, int) int.
> var IntMin = Min[int]
>
> ?
>
> The constraints don't change midway through a program, but in your
> example the meaning of T does change.
>
> Ian
>
>
> > On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote:
> >>
> >> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com  
> wrote:
> >> >
> >> > Quick question...
> >> >
> >> > Why do we need brackets to define a parametered function, struct 
> etc...?
> >> >
> >> > Why not change Go kinds to accept either a type (would produce a 
> regular, function, structs, etc) or a new type parameter object that would 
> implement the constraints (would produce a generic function definition)
> >> >
> >> > for instance,
> >> >
> >> > type parameter T
> >> >
> >> > // [...] some way to add constraint to T
> >> >
> >> > func Max(v T) T{...}
> >> >
> >> > What are the brackets for? Just an idea.
> >>
> >> Each call to Max can use a different value for T. We can call
> >> Max[int] and Max[string]. How would we do that with this notation?
> >>
> >> A type parameter really is a parameter to the function. Making it
> >> syntactically similar to other non-type parameters seems like a good
> >> idea to me.
> >>
> >> Ian
> >
> > --
> > 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/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%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/5eb1bc1e-49a3-4340-83b2-a375b0ad65b4n%40googlegroups.com.

Re: [go-nuts] Type parameters syntax... Can it be improved?

[atd...@gmail.com]

Nevermind, I forgot about function return values.

Difficult to infer them without specifying them, isn'it?

Sorry... should have thought better.
On Wednesday, March 24, 2021 at 12:23:12 AM UTC+1 atd...@gmail.com wrote:

> Mmmh, :/ depends. What is the type of IntMin for the compiler in your 
> example? The same as Min?
>
> If not, it is basically defining a regular function out of a generic 
> function definition.
> So it is merely about constraining the type parameter further to be of 
> specific type int.
>
> A simple closure would be a sensible way to deal with it easily. In 
> general, one would define a general closure function with new type 
> parameters that have aditional constraints.
>
> Trying to see type parameters more like concrete types and interface 
> types, just with different constraints enforced at compile-time than those 
> of types and interface types.
> Could make brackets redundant.
> On Tuesday, March 23, 2021 at 11:22:51 PM UTC+1 Ian Lance Taylor wrote:
>
>> On Tue, Mar 23, 2021 at 3:19 PM atd...@gmail.com  
>> wrote: 
>> > 
>> > Since, we also know the type of v, It would be infered from it. 
>> > 
>> > There is no variance, no dependent type... Meaning that the type of a 
>> Go variable does not change. 
>> > So the constraints do not change midway through the program, including 
>> type names/definitions. 
>> > 
>> > It does however require to have something that resemble a type 
>> definition beforehand. 
>> > A type parameter definition. 
>>
>> In some cases it can be inferred. But what about cases where it 
>> can't? And what if I want to write 
>>
>> // IntMin is a function with type func(int, int) int. 
>> var IntMin = Min[int] 
>>
>> ? 
>>
>> The constraints don't change midway through a program, but in your 
>> example the meaning of T does change. 
>>
>> Ian 
>>
>>
>> > On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote: 
>> >> 
>> >> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com  
>> wrote: 
>> >> > 
>> >> > Quick question... 
>> >> > 
>> >> > Why do we need brackets to define a parametered function, struct 
>> etc...? 
>> >> > 
>> >> > Why not change Go kinds to accept either a type (would produce a 
>> regular, function, structs, etc) or a new type parameter object that would 
>> implement the constraints (would produce a generic function definition) 
>> >> > 
>> >> > for instance, 
>> >> > 
>> >> > type parameter T 
>> >> > 
>> >> > // [...] some way to add constraint to T 
>> >> > 
>> >> > func Max(v T) T{...} 
>> >> > 
>> >> > What are the brackets for? Just an idea. 
>> >> 
>> >> Each call to Max can use a different value for T. We can call 
>> >> Max[int] and Max[string]. How would we do that with this notation? 
>> >> 
>> >> A type parameter really is a parameter to the function. Making it 
>> >> syntactically similar to other non-type parameters seems like a good 
>> >> idea to me. 
>> >> 
>> >> Ian 
>> > 
>> > -- 
>> > 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/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%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/23765669-8548-4977-abd9-fe5b183f4461n%40googlegroups.com.

[go-nuts] Issue: x/net/html Node and attributes constructor function

[atd...@gmail.com]

Just wondering if people would feel it worthy to have COnstructor functions 
to create html.Nodes, attributes, and set attributes on html.Nodes.

I'm writing some kind of metaframework targeting the web and mobile (think 
flutter for Go) and basically finished the web target via wasm.

But I'd like to convert the app tree into an html node tree for static 
generation of pages (think isomorphic app server or whatever the 
terminology frontend dev use nowadays)

After having looked at different solutions, x/net/html seems simple enough 
albeit a bit lacking.

Maybe it is by design for people to build upon it though.

So, do I prepare PRs or just build on it for myself?

-- 
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/08d87d51-2140-4461-b4d5-b4d6603dc1b1n%40googlegroups.com.

[go-nuts] Re: Issue: x/net/html Node and attributes constructor function

[atd...@gmail.com]

Like func NewNode(...) and func NewAttr(...)

Also a SetAttr on Nodes

On Monday, July 12, 2021 at 7:38:08 PM UTC+2 atd...@gmail.com wrote:

> Just wondering if people would feel it worthy to have COnstructor 
> functions to create html.Nodes, attributes, and set attributes on 
> html.Nodes.
>
> I'm writing some kind of metaframework targeting the web and mobile (think 
> flutter for Go) and basically finished the web target via wasm.
>
> But I'd like to convert the app tree into an html node tree for static 
> generation of pages (think isomorphic app server or whatever the 
> terminology frontend dev use nowadays)
>
> After having looked at different solutions, x/net/html seems simple enough 
> albeit a bit lacking.
>
> Maybe it is by design for people to build upon it though.
>
> So, do I prepare PRs or just build on it for myself?
>

-- 
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/9f51f7fc-10c0-486c-a459-a7acec0a331cn%40googlegroups.com.

[go-nuts] syscall/js: wasm perf question

[atd...@gmail.com]

Hi,

I am trying to optimize some wasm code that runs into the browser.
So far, the performance is acceptable if not slightly faster than probably 
unoptimized js DOM manipulation (comparing my implementation of TODOMVC 
with the vanilla javascript one and react one)

One issue I see is that  triggering event handlers that calls into wasm 
seem to incur a big overhead penalty (~25ms)

Any idea if this is normal and ways to alleviate it if so? (I haven.t tried 
using tinyGo yet)

You can find a screenshot of the perf profile here : CDT Perf Profile 
screenshot 

Many thanks,

-- 
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/3d7428d4-dc2f-4faf-84f0-386bce5519ffn%40googlegroups.com.

[go-nuts] Re: syscall/js: wasm perf question

[atd...@gmail.com]

Seems like it might be a slow handling of wasm in Chrome. Firefox is almost 
twice as fast. There seems to be almost no overhead.

On Tuesday, May 31, 2022 at 3:19:24 PM UTC+2 atd...@gmail.com wrote:

> Hi,
>
> I am trying to optimize some wasm code that runs into the browser.
> So far, the performance is acceptable if not slightly faster than probably 
> unoptimized js DOM manipulation (comparing my implementation of TODOMVC 
> with the vanilla javascript one and react one)
>
> One issue I see is that  triggering event handlers that calls into wasm 
> seem to incur a big overhead penalty (~25ms)
>
> Any idea if this is normal and ways to alleviate it if so? (I haven.t 
> tried using tinyGo yet)
>
> You can find a screenshot of the perf profile here : CDT Perf Profile 
> screenshot <https://ibb.co/3SvcySG>
>
> Many thanks,
>

-- 
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/4f9d1cc7-a5e2-4b68-a0a6-c40534e34689n%40googlegroups.com.

[go-nuts] Re: syscall/js: wasm perf question

[atd...@gmail.com]

Really weird, for a same TODOMVC react app, Chrome (101.0.4951.64)  seems 
to be faster than Firefox (77.0.1) at handling a same DOM event (~12ms vs 
~30ms).
But with my implementation of the same TODOMVC app in wasm, built with Go, 
the same event is handled much faster in Firefox than in Chrome (~25ms vs 
~50+ms). 
(And actually wasm event handling is slightly faster than the handling of 
the same event in react)

Mostly seems to me like calling into wasm has close to no overhead in 
Firefox.

Anyone noticed something similar? Perhaps that it warrants a report.
On Wednesday, June 1, 2022 at 8:51:43 PM UTC+2 atd...@gmail.com wrote:

> Seems like it might be a slow handling of wasm in Chrome. Firefox is 
> almost twice as fast. There seems to be almost no overhead.
>
> On Tuesday, May 31, 2022 at 3:19:24 PM UTC+2 atd...@gmail.com wrote:
>
>> Hi,
>>
>> I am trying to optimize some wasm code that runs into the browser.
>> So far, the performance is acceptable if not slightly faster than 
>> probably unoptimized js DOM manipulation (comparing my implementation of 
>> TODOMVC with the vanilla javascript one and react one)
>>
>> One issue I see is that  triggering event handlers that calls into wasm 
>> seem to incur a big overhead penalty (~25ms)
>>
>> Any idea if this is normal and ways to alleviate it if so? (I haven.t 
>> tried using tinyGo yet)
>>
>> You can find a screenshot of the perf profile here : CDT Perf Profile 
>> screenshot <https://ibb.co/3SvcySG>
>>
>> Many thanks,
>>
>

-- 
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/d4d4d6db-e352-41b6-add7-b4ecfdf03a6an%40googlegroups.com.

[go-nuts] Re: Functions vs Methods: explain reasoning behind STD

[atd...@gmail.com]

A short way to see it for me is to reason in terms of capabilities.
What is an instance of a given type supposed to be able to do? (method) 
versus what am I able to do with or upon a given instance (function).
It's not always clear though but it can help.
On Thursday, June 2, 2022 at 4:38:37 PM UTC+2 h...@deividaspetraitis.lt 
wrote:

> Background: when I am writing code mostly I end up with some clunky 
> solutions I am not happy with and one of the reasons I think is that I 
> might be mixing funcs vs methods.
>
> So the question is basically the title.
>
> I have searched both in this group ( without a luck )  and in the Internet 
> for possible ideas/answers and I end up with following points:
>
> 1. Structs are for representing things, they are things
> 2. Funcs are for performing actions, calculating things
> 3. Methods for performing actions on thing state
> 4. Methods to satisfy interface
>
> Based on these points, let's have a "thing":
>
> ```
> type Person struct {
>weight float32 // pounds
>height float32 // inches
> }
> ```
>
> And calculate BMI:
>
> ```
> func CalculateBMI(weight float32 height float32) float32 {
>  return weight / (height * height) x 703
> }
>
> p := Person{157, 66}
>
> CalculateBMI(p.weight, p.height)
> ```
>
> However if I would want for example to implement some kind of interface I 
> would be forced to use method over func, but it looks weird to me for some 
> reason:
>
> ```
> interface BMICalculator {
> CalculateBMI() float32
> }
>
> // Satisfies BMICalculator
> func (p * Person) CalculateBMI() float32 {
>  return p.weight / (p.height * p.height) x 703
> }
> ```
>
> For example when looking at this STD code I am not longer to reason about 
> choices funcs vs methods based on points above: 
> https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;l=26;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708
>
> Why `(a 
> 
>  *TCPAddr 
> 
> ) family 
> ()`
>  
> is implemented as a method when it can be implemented as pure func like:
>
> ``` 
> func Family 
> 
> (a 
> 
>  *TCPAddr 
> )
>  
> int 
> 
>  
> {
>if a 
> 
>  
> == nil || len(a 
> 
> .IP 
> )
>  
> <= IPv4len 
> 
>  
> { 
>return syscall .AF_INET 
> 
>  
>} 
>if a 
> 
> .IP 
> 
> .To4 
> ()
>  
> != nil { 
>return syscall .AF_INET 
> 
>  
>} 
>return syscall .AF_INET6 
> 

[go-nuts] Quick poll: Which of these declarative UI trees looks the most legible to you?

[atd...@gmail.com]

Hi,

So I have a working implementation of a UI framework underway.
I've ended up providing ways to define the UI tree in a declarative way.


But to make sure it is legible, I have a gist with 3 examples of how the UI 
tree could be defined. (taken from an implementation of TODOMVC)
https://gist.github.com/atdiar/0d829060221ecb016c6001761b89d202

1. Full declarative structure specification but CSS classes are added 
outside of the tree.
Also, not very componentized.

2. Declarative but using components defined imperatively. CSS added in-tree 
as a modifier function.

3. Same as above but CSS is added outside of the tree.

Which one do you prefer? Any suggestions to improve?

==


-- 
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/203b1251-60d7-42b8-851d-d5b978b1c7a3n%40googlegroups.com.

[go-nuts] Re: Quick poll: Which of these declarative UI trees looks the most legible to you?

[atd...@gmail.com]

Hey,

Yes, they all look kind of similar because they all use function 
composition and are variations of the same tree, just not with the same 
level of expansion.

I've made a new gist that shows more distinct approaches.

https://gist.github.com/atdiar/725844d85d4b9835c58f7f834570ab69

Thanks for checking, it's really appreciated.



On Wednesday, June 8, 2022 at 12:06:53 PM UTC+2 a2800276 wrote:

> To be honest: on first glance, they all look identical to me apart from 
> the missing AddClass statements in the  last example.
> Would it be possible to have some examples with less subtle differences?
>
> ¯\_(ツ)_/¯ sorry
>
>
>

-- 
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/df5247ef-bb72-4d2a-a613-3ba1b96d876en%40googlegroups.com.

[go-nuts] Re: Quick poll: Which of these declarative UI trees looks the most legible to you?

[atd...@gmail.com]

Someone did suggest implementing the tree using structs to reduce 
indentation. 
I thought about it. However, there is no inheritance (thankfully!) and 
types are invariant (no covariance/contravariance) in Go so I'm afraid it 
wouldn't compose. 
Unless I'm missing something? 


On Thursday, June 9, 2022 at 5:59:04 AM UTC+2 Henry wrote:

> Alternatively, you may experiment using structs with exported fields. It 
> may be a bit less verbose.
>
> On Thursday, June 9, 2022 at 8:28:32 AM UTC+7 atd...@gmail.com wrote:
>
>> Hey,
>>
>> Yes, they all look kind of similar because they all use function 
>> composition and are variations of the same tree, just not with the same 
>> level of expansion.
>>
>> I've made a new gist that shows more distinct approaches.
>>
>> https://gist.github.com/atdiar/725844d85d4b9835c58f7f834570ab69
>>
>> Thanks for checking, it's really appreciated.
>>
>>
>>
>> On Wednesday, June 8, 2022 at 12:06:53 PM UTC+2 a2800276 wrote:
>>
>>> To be honest: on first glance, they all look identical to me apart from 
>>> the missing AddClass statements in the  last example.
>>> Would it be possible to have some examples with less subtle differences?
>>>
>>> ¯\_(ツ)_/¯ sorry
>>>
>>>
>>>

-- 
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/433aa92c-f1e4-4508-bbe7-9996c2d6ce14n%40googlegroups.com.

[go-nuts] syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

[atd...@gmail.com]

Hi,

I just have a quick question.
I am using callbacks that run Go code to modify a Go-wasm datastructure.
These callbacks are essentially Wrapped Go Funcs called from js.

Reading the docs, I've realized that each callback runs in its own 
goroutine.
Now, I'm wondering if I should protect access to the datastructure with 
mutexes.

It's a bit unclear here as I think the current implementation guarantees 
that each callback fully returns before another one gets processed (because 
the event loop is prempted each time a wrapped function gets called until 
it returns). Seems to me that callbacks into Go code can only be 
sequentially processed(?)

Also, if I launch a goroutine in one of these wrapped funcs, when would it 
be scheduled to run? Before the wrapped func it was launched from returns?

Many thanks,


-- 
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/30825eb7-9d54-43a9-a755-5246c9e9be03n%40googlegroups.com.

[go-nuts] Re: syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

[atd...@gmail.com]

Addendum: for the bottom question, I would expect the goroutines launched 
to be scheduled right after the initial callback/wrapped func returns 
unless there is a blocking operation in which case the scheduler might run 
them earlier.
I also do not know if the goroutines would run in a given order, I would 
think it to be potentially random. (in the case multiple goroutines were 
launched within a callback)

All this before any other callback can be called from js.

Is that right? (still unsure of what it entails in terms of synchronization 
requirements)

On Saturday, July 2, 2022 at 3:40:10 PM UTC+2 atd...@gmail.com wrote:

> Hi,
>
> I just have a quick question.
> I am using callbacks that run Go code to modify a Go-wasm datastructure.
> These callbacks are essentially Wrapped Go Funcs called from js.
>
> Reading the docs, I've realized that each callback runs in its own 
> goroutine.
> Now, I'm wondering if I should protect access to the datastructure with 
> mutexes.
>
> It's a bit unclear here as I think the current implementation guarantees 
> that each callback fully returns before another one gets processed (because 
> the event loop is prempted each time a wrapped function gets called until 
> it returns). Seems to me that callbacks into Go code can only be 
> sequentially processed(?)
>
> Also, if I launch a goroutine in one of these wrapped funcs, when would it 
> be scheduled to run? Before the wrapped func it was launched from returns?
>
> Many thanks,
>
>
>

-- 
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/7a0b4bf0-ef11-4123-a4e3-13de01217b43n%40googlegroups.com.

[go-nuts] Re: syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

[atd...@gmail.com]

Ok so I am still trying to figure out what this paragraph entails:
> Invoking the wrapped Go function from JavaScript will pause the event 
loop and spawn a new goroutine. Other wrapped functions which are triggered 
during a call from Go to JavaScript get executed on the same goroutine.

> As a consequence, if one wrapped function blocks, JavaScript's event loop 
is blocked until that function returns. Hence, calling any async JavaScript 
API, which requires the event loop, like fetch (http.Client), will cause an 
immediate deadlock. Therefore > a blocking function should explicitly start 
a new goroutine.
As far as I understand, it means that only one wasm callback function can 
be run at a time and it will be run in a new goroutine. So there should be 
a happens-before edge here. Sequential ordering of synchronous callbacks 
should be kept. That does not require synchronization.

However, within that goroutine, other goroutines may be spawned. Naively, I 
would be tempted to say that it then may require synchronization.
But what makes me hesitate is that preempting the main goroutine and 
running a spawned goroutine that calls a wrapped function that requires the 
use of the event loop would block?
So how are goroutines scheduled here?
Can goroutines be interleaved? How does it not block then if several 
goroutines have to interact with the event loop?

Am I misunderstanding something?
On Saturday, July 2, 2022 at 3:57:11 PM UTC+2 atd...@gmail.com wrote:

> Addendum: for the bottom question, I would expect the goroutines launched 
> to be scheduled right after the initial callback/wrapped func returns 
> unless there is a blocking operation in which case the scheduler might run 
> them earlier.
> I also do not know if the goroutines would run in a given order, I would 
> think it to be potentially random. (in the case multiple goroutines were 
> launched within a callback)
>
> All this before any other callback can be called from js.
>
> Is that right? (still unsure of what it entails in terms of 
> synchronization requirements)
>
> On Saturday, July 2, 2022 at 3:40:10 PM UTC+2 atd...@gmail.com wrote:
>
>> Hi,
>>
>> I just have a quick question.
>> I am using callbacks that run Go code to modify a Go-wasm datastructure.
>> These callbacks are essentially Wrapped Go Funcs called from js.
>>
>> Reading the docs, I've realized that each callback runs in its own 
>> goroutine.
>> Now, I'm wondering if I should protect access to the datastructure with 
>> mutexes.
>>
>> It's a bit unclear here as I think the current implementation guarantees 
>> that each callback fully returns before another one gets processed (because 
>> the event loop is prempted each time a wrapped function gets called until 
>> it returns). Seems to me that callbacks into Go code can only be 
>> sequentially processed(?)
>>
>> Also, if I launch a goroutine in one of these wrapped funcs, when would 
>> it be scheduled to run? Before the wrapped func it was launched from 
>> returns?
>>
>> Many thanks,
>>
>>
>>

-- 
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/a886981d-bec2-4b08-bf40-6be660acaef3n%40googlegroups.com.

[go-nuts] Re: syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

[atd...@gmail.com]

ok so, thinking about it again, I guess that here, there is no preemption 
point within functions. So when a wrapped function returns, the event loop 
resumes and it is then ok to call another wrapped function which may use 
the event loop.
However, there could be an issue if the wasm code were able to multiplex 
goroutines on different threads (I don't think that is the case yet) since 
there is  potentially simultaneous access by different goroutines.
So concurrent access needs to be serialized in my case, I think.




On Monday, July 4, 2022 at 4:27:04 AM UTC+2 atd...@gmail.com wrote:

> Ok so I am still trying to figure out what this paragraph entails:
> > Invoking the wrapped Go function from JavaScript will pause the event 
> loop and spawn a new goroutine. Other wrapped functions which are triggered 
> during a call from Go to JavaScript get executed on the same goroutine.
>
> > As a consequence, if one wrapped function blocks, JavaScript's event 
> loop is blocked until that function returns. Hence, calling any async 
> JavaScript API, which requires the event loop, like fetch (http.Client), 
> will cause an immediate deadlock. Therefore > a blocking function should 
> explicitly start a new goroutine.
> As far as I understand, it means that only one wasm callback function can 
> be run at a time and it will be run in a new goroutine. So there should be 
> a happens-before edge here. Sequential ordering of synchronous callbacks 
> should be kept. That does not require synchronization.
>
> However, within that goroutine, other goroutines may be spawned. Naively, 
> I would be tempted to say that it then may require synchronization.
> But what makes me hesitate is that preempting the main goroutine and 
> running a spawned goroutine that calls a wrapped function that requires the 
> use of the event loop would block?
> So how are goroutines scheduled here?
> Can goroutines be interleaved? How does it not block then if several 
> goroutines have to interact with the event loop?
>
> Am I misunderstanding something?
> On Saturday, July 2, 2022 at 3:57:11 PM UTC+2 atd...@gmail.com wrote:
>
>> Addendum: for the bottom question, I would expect the goroutines launched 
>> to be scheduled right after the initial callback/wrapped func returns 
>> unless there is a blocking operation in which case the scheduler might run 
>> them earlier.
>> I also do not know if the goroutines would run in a given order, I would 
>> think it to be potentially random. (in the case multiple goroutines were 
>> launched within a callback)
>>
>> All this before any other callback can be called from js.
>>
>> Is that right? (still unsure of what it entails in terms of 
>> synchronization requirements)
>>
>> On Saturday, July 2, 2022 at 3:40:10 PM UTC+2 atd...@gmail.com wrote:
>>
>>> Hi,
>>>
>>> I just have a quick question.
>>> I am using callbacks that run Go code to modify a Go-wasm datastructure.
>>> These callbacks are essentially Wrapped Go Funcs called from js.
>>>
>>> Reading the docs, I've realized that each callback runs in its own 
>>> goroutine.
>>> Now, I'm wondering if I should protect access to the datastructure with 
>>> mutexes.
>>>
>>> It's a bit unclear here as I think the current implementation guarantees 
>>> that each callback fully returns before another one gets processed (because 
>>> the event loop is prempted each time a wrapped function gets called until 
>>> it returns). Seems to me that callbacks into Go code can only be 
>>> sequentially processed(?)
>>>
>>> Also, if I launch a goroutine in one of these wrapped funcs, when would 
>>> it be scheduled to run? Before the wrapped func it was launched from 
>>> returns?
>>>
>>> Many thanks,
>>>
>>>
>>>

-- 
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/2fd151f9-e4a1-4980-9bed-949963ad9e4en%40googlegroups.com.

[go-nuts] Do I need a reentrant locks?

[atd...@gmail.com]

Hi,

I have a tree datastructure where mutating some nodes *may *trigger a 
mutation on some other tree nodes.

This tree should be accessible by multiple goroutines but mutated by only 
one at a time.

As such, I wanted to have a global lock on the tree such that mutatiing 
node methods should acquire this lock beforehand.

But it seems to require for the mutex to be reentrant? 

I have tried to create a very simplified*** model to 
illustrate https://go.dev/play/p/v37cbYQ1jSY

(***) I know people might want to suggest for the Set method to use a 
lockless variant when iterating over the linked nodes but in the real code, 
it iterates over user created callbacks instead and I don't think I can 
expect callbacks writers to juggle between the two kind of methods to avoid 
deadlocks.

Any suggestion?

-- 
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/56e19366-13f0-4be4-aa01-7df7bbf424b3n%40googlegroups.com.

[go-nuts] Re: Do I need a reentrant locks?

[atd...@gmail.com]

:) That's what the asterisked note was for in the original question. I 
don't think I can do that in the real code because the real code is much 
more complex. Each node actually triggers a callback that may modify 
another node. That callback is user-created, not framework created so I 
have no way of knowing if the lock has already been taken.

And I wouldn't want for library users to have to make that distinction 
themselves.

On Tuesday, July 5, 2022 at 3:48:16 PM UTC+2 Brian Candler wrote:

> Have a public Set() that does the lock and then calls a private internal 
> function, which assumes it's already running under the lock.
> https://go.dev/play/p/M1XuC8bxCxL
>
> On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote:
>
>> Hi,
>>
>> I have a tree datastructure where mutating some nodes *may *trigger a 
>> mutation on some other tree nodes.
>>
>> This tree should be accessible by multiple goroutines but mutated by only 
>> one at a time.
>>
>> As such, I wanted to have a global lock on the tree such that mutatiing 
>> node methods should acquire this lock beforehand.
>>
>> But it seems to require for the mutex to be reentrant? 
>>
>> I have tried to create a very simplified*** model to illustrate 
>> https://go.dev/play/p/v37cbYQ1jSY
>>
>> (***) I know people might want to suggest for the Set method to use a 
>> lockless variant when iterating over the linked nodes but in the real code, 
>> it iterates over user created callbacks instead and I don't think I can 
>> expect callbacks writers to juggle between the two kind of methods to avoid 
>> deadlocks.
>>
>> Any suggestion?
>>
>>

-- 
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/db0206a8-b113-47ba-9aa5-b3d3680870e2n%40googlegroups.com.

Re: [go-nuts] Re: Do I need a reentrant locks?

[atd...@gmail.com]

You're absolutely right. (I wrote the simplified example a bit too fast and 
missed that in a few places https://go.dev/play/p/9fk_yt0vkHD) 

To add the general motivation, I have a reactive UI tree and need to 
introduce concurrency (for when async data fetching is done and the data is 
reintroduced,, essentially mutating the tree).

On Tuesday, July 5, 2022 at 4:13:01 PM UTC+2 Marvin Renich wrote:

> * Brian Candler  [220705 09:48]:
> > Have a public Set() that does the lock and then calls a private internal 
> > function, which assumes it's already running under the lock.
> > https://go.dev/play/p/M1XuC8bxCxL
> > 
> > On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote:
> > 
> > > Hi,
> > >
> > > I have a tree datastructure where mutating some nodes *may *trigger a 
> > > mutation on some other tree nodes.
> > >
> > > This tree should be accessible by multiple goroutines but mutated by 
> only 
> > > one at a time.
> > >
> > > As such, I wanted to have a global lock on the tree such that 
> mutatiing 
> > > node methods should acquire this lock beforehand.
> > >
> > > But it seems to require for the mutex to be reentrant? 
> > >
> > > I have tried to create a very simplified*** model to illustrate 
> > > https://go.dev/play/p/v37cbYQ1jSY
> > >
> > > (***) I know people might want to suggest for the Set method to use a 
> > > lockless variant when iterating over the linked nodes but in the real 
> code, 
> > > it iterates over user created callbacks instead and I don't think I 
> can 
> > > expect callbacks writers to juggle between the two kind of methods to 
> avoid 
> > > deadlocks.
> > >
> > > Any suggestion?
> > >
> > >
>
> Note also that for referencing a Node to be safe, you must do one of two
> things: either use sync/atomic for all reads and writes of Num
> (assuming the data in the tree is of a type that can be handled by
> sync/atomic), or use sync.RWMutex instead of sync.Mutex, and use RLock
> on reads and Lock on writes.
>
> If Node has more than one data field, e.g. {Name string; Age int; ...},
> you will have to go with the RWMutex option.
>
> ...Marvin
>
>

-- 
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/94b3ef70-9431-4a8a-916d-034dd5822d01n%40googlegroups.com.

Re: [go-nuts] Do I need a reentrant locks?

[atd...@gmail.com]

Well, in my case, only the writing goroutine should be able to have access 
to the datastructure (to keep the invariants). So I think a mutex should do 
the trick.
Indeed, it looks like transactions or a reimplementation of a UI 
thread/event loop.


A concurrent hash=array mapped trie might indeed help if reads had to 
happen concurrently with writes.
In my experience though, this is allocation heavy and for one of my current 
targets, it might be impractical: wasm in the browser is highly sensitive 
to allocations and those concurrent datastructures rely heavily on 
copy-on-write.

For now, my main idea is to deal with establishing critical sections in the 
main goroutine (which is framework handled so should be fine)
and unfortunately, document that framework users spawning their own 
goroutine should establish a critical section where all tree 
access/mutation should happen, by taking the global lock.

One alternative would be storing operations into a queue as suggested and 
then passing it to a tree modifying goroutine. Might be better although it 
might add some API surface. Need to think about it.



On Wednesday, July 6, 2022 at 1:58:01 PM UTC+2 ren...@ix.netcom.com wrote:

> Depends on if you “concurrent” readers or serialized interlaced ones. 
>
> It depends on you transaction semantics - eg dirty reads, etc. 
>
> It is fairly easy for readers to grab the read lock and the writer thread 
> (since they were added to a queue) to grab the write lock when it has work 
> to do. 
>
> Like I said, a copy on write - partitioned - can be highly effective. 
>
> Review the ConcurrentHashMap source for an efficient implementation of a 
> complex data structure that is highly concurrent for both reading and 
> writing. 
>
> If you have a tree, you would most likely partition by branches. 
>
> The idea is to mutate only a portion of the structure and efficiently swap 
> it it when ready. 
>
> On Jul 6, 2022, at 5:59 AM, Brian Candler  wrote:
>
> 
>
> On Wednesday, 6 July 2022 at 11:33:29 UTC+1 ren...@ix.netcom.com wrote:
>
>> As I said, make the mutating op simply record the desired op on a queue 
>> and process the serially on another thread.  You are essentially 
>> implementing transactions. 
>>
>
> But how do you protect tree *readers* from having mutations take place 
> under their feet? You could serialize all reads as well, and copy the 
> results. But I don't think that's what the OP was intending.
>
> You could have aRWMutex, but then it's up to the API caller to obtain that 
> mutex *for as long as necessary* (e.g. while traversing part of the tree).
>
> Depending on the use case, a "functional" approach might be worth 
> considering:
> - nodes are strictly immutable
> - if you need to modify a node, create a new node instead
> - recursively repeat for every other node that holds a pointer to this 
> node.
> - atomically update the "tree root" pointer
>
> Then each reader sees a snapshot of the tree at a point in time, and 
> garbage collection should take care of the rest.
>
> -- 
>
> 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/888413c1-d4ff-4752-a607-2a3f2196e1dfn%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/4f280bbe-e92e-42af-8779-9d72ac16c8a4n%40googlegroups.com.

[go-nuts] Re: syscall/js (wasm): Wrapped func, goroutines, GOMAXPROCS, mutex necessity?

[atd...@gmail.com]

Still pondering on this.
Apparently, can't use a shared-access mutex within event handling 
callbacks. It deadlocks. Which might be normal if my unbderstand is correct 
in that the Wrapped funcs are almost always called in the same goroutine 
(the exception being due to promise callbacks).
Other wrapped funcs that call into other goroutines have a write barrier 
(around handleAsynEvent) so there is probably no need to fiddle with locks 
here?

https://cs.opensource.google/go/go/+/master:src/runtime/lock_js.go;l=218?q=handleAsyncEvent&sq=&ss=go%2Fgo:src%2Fruntime%2F

Might have to change how I see this if/when multithreaded support is 
introduced.


On Monday, July 4, 2022 at 3:24:01 PM UTC+2 atd...@gmail.com wrote:

> ok so, thinking about it again, I guess that here, there is no preemption 
> point within functions. So when a wrapped function returns, the event loop 
> resumes and it is then ok to call another wrapped function which may use 
> the event loop.
> However, there could be an issue if the wasm code were able to multiplex 
> goroutines on different threads (I don't think that is the case yet) since 
> there is  potentially simultaneous access by different goroutines.
> So concurrent access needs to be serialized in my case, I think.
>
>
>
>
> On Monday, July 4, 2022 at 4:27:04 AM UTC+2 atd...@gmail.com wrote:
>
>> Ok so I am still trying to figure out what this paragraph entails:
>> > Invoking the wrapped Go function from JavaScript will pause the event 
>> loop and spawn a new goroutine. Other wrapped functions which are triggered 
>> during a call from Go to JavaScript get executed on the same goroutine.
>>
>> > As a consequence, if one wrapped function blocks, JavaScript's event 
>> loop is blocked until that function returns. Hence, calling any async 
>> JavaScript API, which requires the event loop, like fetch (http.Client), 
>> will cause an immediate deadlock. Therefore > a blocking function should 
>> explicitly start a new goroutine.
>> As far as I understand, it means that only one wasm callback function can 
>> be run at a time and it will be run in a new goroutine. So there should be 
>> a happens-before edge here. Sequential ordering of synchronous callbacks 
>> should be kept. That does not require synchronization.
>>
>> However, within that goroutine, other goroutines may be spawned. Naively, 
>> I would be tempted to say that it then may require synchronization.
>> But what makes me hesitate is that preempting the main goroutine and 
>> running a spawned goroutine that calls a wrapped function that requires the 
>> use of the event loop would block?
>> So how are goroutines scheduled here?
>> Can goroutines be interleaved? How does it not block then if several 
>> goroutines have to interact with the event loop?
>>
>> Am I misunderstanding something?
>> On Saturday, July 2, 2022 at 3:57:11 PM UTC+2 atd...@gmail.com wrote:
>>
>>> Addendum: for the bottom question, I would expect the goroutines 
>>> launched to be scheduled right after the initial callback/wrapped func 
>>> returns unless there is a blocking operation in which case the scheduler 
>>> might run them earlier.
>>> I also do not know if the goroutines would run in a given order, I would 
>>> think it to be potentially random. (in the case multiple goroutines were 
>>> launched within a callback)
>>>
>>> All this before any other callback can be called from js.
>>>
>>> Is that right? (still unsure of what it entails in terms of 
>>> synchronization requirements)
>>>
>>> On Saturday, July 2, 2022 at 3:40:10 PM UTC+2 atd...@gmail.com wrote:
>>>
>>>> Hi,
>>>>
>>>> I just have a quick question.
>>>> I am using callbacks that run Go code to modify a Go-wasm datastructure.
>>>> These callbacks are essentially Wrapped Go Funcs called from js.
>>>>
>>>> Reading the docs, I've realized that each callback runs in its own 
>>>> goroutine.
>>>> Now, I'm wondering if I should protect access to the datastructure with 
>>>> mutexes.
>>>>
>>>> It's a bit unclear here as I think the current implementation 
>>>> guarantees that each callback fully returns before another one gets 
>>>> processed (because the event loop is prempted each time a wrapped function 
>>>> gets called until it returns). Seems to me that callbacks into Go code can 
>>>> only be sequentially processed(?)
>>>>
>>>> Also, if I launch a goroutine in one of these wrapped funcs, when would 
>>>> it be scheduled to run? Before the wrapped func it was launched from 
>>>> returns?
>>>>
>>>> Many thanks,
>>>>
>>>>
>>>>

-- 
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/2d858fd9-3967-45a7-9417-da47bd54d2a1n%40googlegroups.com.

[go-nuts] syscall/js: strange deadlock caused by wasm event handling callback (runtime bug?)

[atd...@gmail.com]

Hi,

I have a little concurrency problem. Seems that my Go-wasm-defined event 
handlers run concurrently instead of synchronously.

Basically, the event handler is called by runtime.handleEvent which calls 
into the syscall/js defined version of it

Link to source 

// handleEvent gets invoked on a call from JavaScript into Go. It calls the 
event handler of the syscall/js package 
// and then parks the handler goroutine to allow other goroutines to run 
before giving execution back to JavaScript. 
// When no other goroutine is awake any more, beforeIdle resumes the 
handler goroutine. Now that the same goroutine 
// is running as was running when the call came in from JavaScript, 
execution can be safely passed back to JavaScript. 
func handleEvent() { 
   e := &event{ 
   gp: getg(), 
   returned: false, 
   } 
   events = append(events, e) 
   *eventHandler() // *
   clearIdleID() 
   // wait until all goroutines are idle 
   e.returned = true 
   gopark(nil, nil, waitReasonZero, traceEvNone, 1) 
   events[len(events)-1] = nil 
   events = events[:len(events)-1] 
   // return execution to JavaScript 
   pause(getcallersp() - 16) 
}

In syscall/js, Link to source 

func handleEvent() { 
   cb := jsGo.Get("_pendingEvent") 
   if cb.IsNull() { 
   return 
   } 
   jsGo.Set("_pendingEvent", Null()) 
   id := uint32(cb.Get("id").Int()) 
   if id == 0 { // zero indicates deadlock 
   select {} 
   } 
   funcsMu.Lock() 
   f, ok := funcs[id] 
   funcsMu.Unlock() 
   if !ok { 
   Global().Get("console").Call("error", "call to released function") 
   return 
   } 
   this := cb.Get("this") 
   argsObj := cb.Get("args") 
   args := make([]Value, argsObj.Length()) 
   for i := range args { 
   args[i] = argsObj.Index(i) 
   } 
   *result := f(this, args) // My callback runs here*
   cb.Set("result", result) 
}


Basically, f causes a deadlock because it locks a mutex but never unlocks 
before being called again in response to another JS event.
If I remove the lock, it's fine but he program should be incorrect as event 
handlers should be run synchronously.

*Tried to instrument the code to display the call stack. You can see toward 
the end that there is an attempt to take a lock while handling the focus 
event that has not been unlocked beforehand while processing the click 
event.*

2022/08/05 22:24:25 focusTodo-App
wasm_exec.js:22 2022/08/05 22:24:25 LOCKING 

wasm_exec.js:22 2022/08/05 22:24:25 LOCkED 
--
wasm_exec.js:22 2022/08/05 22:24:25 6
wasm_exec.js:22 runtime.Callers
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.glob..func2.1
wasm_exec.js:22 syscall/js.handleEvent
wasm_exec.js:22 runtime.handleEvent
wasm_exec.js:22 runtime.goexit
wasm_exec.js:22 2022/08/05 22:24:25 UNLOCKING 

wasm_exec.js:22 2022/08/05 22:24:25 7
wasm_exec.js:22 runtime.Callers
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.freelock
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.glob..func2.1
wasm_exec.js:22 syscall/js.handleEvent
wasm_exec.js:22 runtime.handleEvent
wasm_exec.js:22 runtime.goexit
wasm_exec.js:22 2022/08/05 22:24:25 UNLOCkED 
--
wasm_exec.js:22 2022/08/05 22:24:32 focusTodo-App
wasm_exec.js:22 2022/08/05 22:24:32 LOCKING 

wasm_exec.js:22 2022/08/05 22:24:32 LOCkED 
--
wasm_exec.js:22 2022/08/05 22:24:32 6
wasm_exec.js:22 runtime.Callers
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.glob..func2.1
wasm_exec.js:22 syscall/js.handleEvent
wasm_exec.js:22 runtime.handleEvent
wasm_exec.js:22 runtime.goexit
wasm_exec.js:22 2022/08/05 22:24:32 UNLOCKING 

wasm_exec.js:22 2022/08/05 22:24:32 7
wasm_exec.js:22 runtime.Callers
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.freelock
wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.glob..func2.1
wasm_exec.js:22 syscall/js.handleEvent
wasm_exec.js:22 runtime.handleEvent
wasm_exec.js:22 runtime.goexit
wasm_exec.js:22 2022/08/05 22:24:32 UNLOCkED 
--


*wasm_exec.js:22 2022/08/05 22:24:32 
clickactive-filte

Re: [go-nuts] syscall/js: strange deadlock caused by wasm event handling callback (runtime bug?)

[atd...@gmail.com]

Filed an issue with a reproducer 
;  https://github.com/golang/go/issues/54328

On Sunday, August 7, 2022 at 12:08:33 AM UTC+2 atd...@gmail.com wrote:

> Doesn't seem that this is a known issue. I will try and write a short 
> reproducer and file an issue. 
>
> On Fri, Aug 5, 2022, 11:18 PM atd...@gmail.com  wrote:
>
>> Hi,
>>
>> I have a little concurrency problem. Seems that my Go-wasm-defined event 
>> handlers run concurrently instead of synchronously.
>>
>> Basically, the event handler is called by runtime.handleEvent which calls 
>> into the syscall/js defined version of it
>>
>> Link to source 
>> <https://cs.opensource.google/go/go/+/master:src/runtime/lock_js.go;l=244?q=handlEeVE&sq=&ss=go%2Fgo:src%2Fruntime%2F>
>> // handleEvent gets invoked on a call from JavaScript into Go. It calls 
>> the event handler of the syscall/js package 
>> // and then parks the handler goroutine to allow other goroutines to run 
>> before giving execution back to JavaScript. 
>> // When no other goroutine is awake any more, beforeIdle resumes the 
>> handler goroutine. Now that the same goroutine 
>> // is running as was running when the call came in from JavaScript, 
>> execution can be safely passed back to JavaScript. 
>> func handleEvent() { 
>>e := &event{ 
>>gp: getg(), 
>>returned: false, 
>>} 
>>events = append(events, e) 
>>*eventHandler() // *
>>clearIdleID() 
>>// wait until all goroutines are idle 
>>e.returned = true 
>>gopark(nil, nil, waitReasonZero, traceEvNone, 1) 
>>events[len(events)-1] = nil 
>>events = events[:len(events)-1] 
>>// return execution to JavaScript 
>>pause(getcallersp() - 16) 
>> }
>>
>> In syscall/js, Link to source 
>> <https://cs.opensource.google/go/go/+/master:src/syscall/js/func.go;l=69?q=handleEve&sq=&ss=go%2Fgo>
>> func handleEvent() { 
>>cb := jsGo.Get("_pendingEvent") 
>>if cb.IsNull() { 
>>return 
>>} 
>>jsGo.Set("_pendingEvent", Null()) 
>>id := uint32(cb.Get("id").Int()) 
>>if id == 0 { // zero indicates deadlock 
>>select {} 
>>} 
>>funcsMu.Lock() 
>>f, ok := funcs[id] 
>>funcsMu.Unlock() 
>>if !ok { 
>>Global().Get("console").Call("error", "call to released function") 
>>return 
>>} 
>>this := cb.Get("this") 
>>argsObj := cb.Get("args") 
>>args := make([]Value, argsObj.Length()) 
>>for i := range args { 
>>args[i] = argsObj.Index(i) 
>>} 
>>*result := f(this, args) // My callback runs here*
>>cb.Set("result", result) 
>> }
>>
>>
>> Basically, f causes a deadlock because it locks a mutex but never unlocks 
>> before being called again in response to another JS event.
>> If I remove the lock, it's fine but he program should be incorrect as 
>> event handlers should be run synchronously.
>>
>> *Tried to instrument the code to display the call stack. You can see 
>> toward the end that there is an attempt to take a lock while handling the 
>> focus event that has not been unlocked beforehand while processing the 
>> click event.*
>>
>> 2022/08/05 22:24:25 focusTodo-App
>> wasm_exec.js:22 2022/08/05 22:24:25 LOCKING 
>> 
>> wasm_exec.js:22 2022/08/05 22:24:25 LOCkED 
>> --
>> wasm_exec.js:22 2022/08/05 22:24:25 6
>> wasm_exec.js:22 runtime.Callers
>> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
>> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.glob..func2.1
>> wasm_exec.js:22 syscall/js.handleEvent
>> wasm_exec.js:22 runtime.handleEvent
>> wasm_exec.js:22 runtime.goexit
>> wasm_exec.js:22 2022/08/05 22:24:25 UNLOCKING 
>> 
>> wasm_exec.js:22 2022/08/05 22:24:25 7
>> wasm_exec.js:22 runtime.Callers
>> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
>> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.freelock
>> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.glob..func2.1
>> wasm_exec.js:22 syscall/js.handleEvent
>> wasm_exec.js:22 runtime.handleEvent
>> wasm_exec.js:22 runtime.goexit
>> wasm_exec.js:22 2022/08/05 

Re: [go-nuts] Do I need a reentrant locks?

[atd...@gmail.com]

So it seems that reentrant locks are a hard requirement after all.
The reason being that an event handler can itself trigger an event which 
will be handled by a similar callback synchronously. (basically, callback 
composition)
If the first event handler locks the UI tree, the next synchronous callback 
will also attempt to take the lock. If no lock reentrancy, it's a deadlock.

This is the same scenario as described here (which doesn't seem to have any 
satisfying answer)  
https://stackoverflow.com/questions/30469808/recursive-critical-sections-in-go

For now, I'm going to take advantage of the fact that there is no goroutine 
preemption in wasm  to make locking in event handling callbacks optional 
(using trylock).
That's a ugly hack, but there is no way around it for now.

***and yes, I have thouhgt about sending mutating functions to a goroutine 
dedicated to call them via a channel (basically a UI thread) but that would 
make the API too cumbersome to use by the end users as they  would now have 
to remember to create closures and put them on a channel. A tedious DX only 
because we need to be concurrent-aware. Not even that concurrency is 
required all the time.



On Wednesday, July 6, 2022 at 3:33:50 PM UTC+2 atd...@gmail.com wrote:

> Well, in my case, only the writing goroutine should be able to have access 
> to the datastructure (to keep the invariants). So I think a mutex should do 
> the trick.
> Indeed, it looks like transactions or a reimplementation of a UI 
> thread/event loop.
>
>
> A concurrent hash=array mapped trie might indeed help if reads had to 
> happen concurrently with writes.
> In my experience though, this is allocation heavy and for one of my 
> current targets, it might be impractical: wasm in the browser is highly 
> sensitive to allocations and those concurrent datastructures rely heavily 
> on copy-on-write.
>
> For now, my main idea is to deal with establishing critical sections in 
> the main goroutine (which is framework handled so should be fine)
> and unfortunately, document that framework users spawning their own 
> goroutine should establish a critical section where all tree 
> access/mutation should happen, by taking the global lock.
>
> One alternative would be storing operations into a queue as suggested and 
> then passing it to a tree modifying goroutine. Might be better although it 
> might add some API surface. Need to think about it.
>
>
>
> On Wednesday, July 6, 2022 at 1:58:01 PM UTC+2 ren...@ix.netcom.com wrote:
>
>> Depends on if you “concurrent” readers or serialized interlaced ones. 
>>
>> It depends on you transaction semantics - eg dirty reads, etc. 
>>
>> It is fairly easy for readers to grab the read lock and the writer thread 
>> (since they were added to a queue) to grab the write lock when it has work 
>> to do. 
>>
>> Like I said, a copy on write - partitioned - can be highly effective. 
>>
>> Review the ConcurrentHashMap source for an efficient implementation of a 
>> complex data structure that is highly concurrent for both reading and 
>> writing. 
>>
>> If you have a tree, you would most likely partition by branches. 
>>
>> The idea is to mutate only a portion of the structure and efficiently 
>> swap it it when ready. 
>>
>> On Jul 6, 2022, at 5:59 AM, Brian Candler  wrote:
>>
>> 
>>
>> On Wednesday, 6 July 2022 at 11:33:29 UTC+1 ren...@ix.netcom.com wrote:
>>
>>> As I said, make the mutating op simply record the desired op on a queue 
>>> and process the serially on another thread.  You are essentially 
>>> implementing transactions. 
>>>
>>
>> But how do you protect tree *readers* from having mutations take place 
>> under their feet? You could serialize all reads as well, and copy the 
>> results. But I don't think that's what the OP was intending.
>>
>> You could have aRWMutex, but then it's up to the API caller to obtain 
>> that mutex *for as long as necessary* (e.g. while traversing part of the 
>> tree).
>>
>> Depending on the use case, a "functional" approach might be worth 
>> considering:
>> - nodes are strictly immutable
>> - if you need to modify a node, create a new node instead
>> - recursively repeat for every other node that holds a pointer to this 
>> node.
>> - atomically update the "tree root" pointer
>>
>> Then each reader sees a snapshot of the tree at a point in time, and 
>> garbage collection should take care of the rest.
>>
>> -- 
>>
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.

[go-nuts] How to abstract away a method implementation and replace it?

[atd...@gmail.com]

I have exposed the following problem in a bit more details here:

https://gist.github.com/atdiar/6568964896231bfde734f6bddf9ff46c

Basically, I need to modify the implementation of the method of a given 
type depending on the encasing scope of the value its called on. (and not 
just the value itself)

the reason being that the value is a func type, not a struct type which I 
could modify to add a reference to external scope/state.


I could easily modify the implementation of the type if we had generealized 
interfaces/ union types. That would solve it at compile time.

But I would be happy just being able to assign a stable id to a func value 
at runtime, as a non-pointer reference. (probably via a runtime pkg 
function).
I can do the latter now using fmt.Sprint on a function but there is no 
guarantee of stability. It's simply that the GC is not a moving compactor 
for instance which may allow it for now.

Any idea?

Can I fill an issue for the stableid idea or that's not somethign that's 
actually possible?


-- 
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/f0b85b9a-4fdf-4565-b59e-835302e0453en%40googlegroups.com.

[go-nuts] Re: How to abstract away a method implementation and replace it?

[atd...@gmail.com]

Suddenly thinking that I can actually just use type parameters but the type 
argument can also created lazily by being instantiations of parametred 
types..

Might actually be sufficient to have value scoped type instantiations.

On Sunday, June 18, 2023 at 1:38:33 PM UTC+2 atd...@gmail.com wrote:

> I have exposed the following problem in a bit more details here:
>
> https://gist.github.com/atdiar/6568964896231bfde734f6bddf9ff46c
>
> Basically, I need to modify the implementation of the method of a given 
> type depending on the encasing scope of the value its called on. (and not 
> just the value itself)
>
> the reason being that the value is a func type, not a struct type which I 
> could modify to add a reference to external scope/state.
>
>
> I could easily modify the implementation of the type if we had 
> generealized interfaces/ union types. That would solve it at compile time.
>
> But I would be happy just being able to assign a stable id to a func value 
> at runtime, as a non-pointer reference. (probably via a runtime pkg 
> function).
> I can do the latter now using fmt.Sprint on a function but there is no 
> guarantee of stability. It's simply that the GC is not a moving compactor 
> for instance which may allow it for now.
>
> Any idea?
>
> Can I fill an issue for the stableid idea or that's not somethign that's 
> actually possible?
>
>
>

-- 
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/a015a9a5-00fa-4d50-a457-6cca1b4369a6n%40googlegroups.com.

[go-nuts] Re: How to abstract away a method implementation and replace it?

[atd...@gmail.com]

Nevermind for the first idea.. this is even more complex than I thought.
First it requires generalized interfaces. I don't see it being a major 
problem in the long run.

But I thought I could work around not having value scoped type declarations 
but turns out it is not the case after all.
Realized that it requires dependent types. (to create new types from some 
value, in my case here, the specific document should have its specific 
Element constructor types)

Don't see that happening any time soon, emphasis on soon, unfortunately.

So I guess, I'd like to be able to hack around this by maintaining my own 
function-value dependencies by hand but that still requires to be able to 
have a stable id for function values.
Essentially, doing dependent types manually.

Should be much easier I think. Just requires a stable id/ reference for 
function values if I'm not mistaken?



On Sunday, June 18, 2023 at 1:38:33 PM UTC+2 atd...@gmail.com wrote:

> I have exposed the following problem in a bit more details here:
>
> https://gist.github.com/atdiar/6568964896231bfde734f6bddf9ff46c
>
> Basically, I need to modify the implementation of the method of a given 
> type depending on the encasing scope of the value its called on. (and not 
> just the value itself)
>
> the reason being that the value is a func type, not a struct type which I 
> could modify to add a reference to external scope/state.
>
>
> I could easily modify the implementation of the type if we had 
> generealized interfaces/ union types. That would solve it at compile time.
>
> But I would be happy just being able to assign a stable id to a func value 
> at runtime, as a non-pointer reference. (probably via a runtime pkg 
> function).
> I can do the latter now using fmt.Sprint on a function but there is no 
> guarantee of stability. It's simply that the GC is not a moving compactor 
> for instance which may allow it for now.
>
> Any idea?
>
> Can I fill an issue for the stableid idea or that's not somethign that's 
> actually possible?
>
>
>

-- 
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/d0a0b0fe-0356-44b7-bd30-529923af9cebn%40googlegroups.com.

Re: [go-nuts] [generics] type constraint for structs

[atd...@gmail.com]

Might have come across this today as I was trying to simplify some code.

Basically, I have a base type called *Element that has a method AsElement() 
*Element that returns itself.

And this base element is used as a base for many others, for isntance:

type Div struct{ *Element}
type Span struct{*Element}
type Anchor {*Element}
...

Somehow, I need a function Ref that can take a pointer to any of these 
elements and modify them (basically modifying the inner *Element pointer).

Currently, I don't think I can abstract over these types which share in 
common the *Element field and the AsEleemnt method promoted from it.
I don't want to have to implement a specific method to do that mutation 
operation for each and every one of these types either.

Basically, trying to make generic this function:

func Ref(vref **Element) func(*Element) *Element{
return func(e *Element)*Element{
*vref = e
return e
}
}


Or does anyone see something that I missed?

On Thursday, April 4, 2024 at 2:52:16 AM UTC+2 Adam Manwaring wrote:

> While this would make some things much easier for me, it seems this would 
> be a pretty fundamental change. Constraints are essentially interfaces and 
> interfaces in Go are defined by behaviors. Structs, on the other hand, are 
> defined by properties. There is no behavior that all structs have that 
> every other type couldn't also have. Thus having a struct constraint would 
> be a one-off exception which for the most part seems anathema to Go. In a 
> similar vein, there are many times I'd like an interface to require certain 
> exported properties in addition to behaviors, but this isn't going to 
> happen.
>
> On Wednesday, March 27, 2024 at 6:28:19 PM UTC-6 Makis Maropoulos wrote:
>
>> Same here @Abraham, 
>>
>> ResponseType interface {
>> ~struct{}
>> }
>>
>> Obviously this doesn't work, I would love to see it working though.
>> On Wednesday 14 September 2022 at 17:48:19 UTC+3 Abraham wrote:
>>
>>> I am glad I found this thread because I was just now breaking my head 
>>> figuring out why my  was not working
>>>
>>> On Wednesday, May 18, 2022 at 10:41:29 PM UTC-4 Ian Lance Taylor wrote:
>>>
 On Wed, May 18, 2022 at 7:36 PM Jeremy Kassis  
 wrote: 
 > 
 > Where exactly did this land? Seems like an important conversation... 

 To date there is no way to write a constraint that requires that a 
 type argument be a struct type. 


 > ``` 
 > // RPCHandler passes RPCReq and RPCRes as fn args 
 > func RPCHandler[T RPCReq, S RPCRes](fn func(T, S)) http.HandlerFunc { 
 > return func(w http.ResponseWriter, r *http.Request) { 
 > req := T{} 
 > if err := reqBodyReadAll(w, r, &req); err != nil { 
 > resWriteErr(w, err) 
 > return 
 > } 
 > res := S{} 
 > fn(req, res) 
 > resWriteAll(w, r, res) 
 > } 
 > } 
 > ``` 

 I would write simply "var req T" and "var res S". 

 Ian 

>>>

-- 
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/f2150cf5-75d9-4cb3-9a29-d5a8c8e655a5n%40googlegroups.com.

Re: [go-nuts] [generics] type constraint for structs

[atd...@gmail.com]

Ah, I forgot to use reflection for instance... That might be doable.

On Thursday, April 4, 2024 at 4:13:35 AM UTC+2 atd...@gmail.com wrote:

> Might have come across this today as I was trying to simplify some code.
>
> Basically, I have a base type called *Element that has a method 
> AsElement() *Element that returns itself.
>
> And this base element is used as a base for many others, for isntance:
>
> type Div struct{ *Element}
> type Span struct{*Element}
> type Anchor {*Element}
> ...
>
> Somehow, I need a function Ref that can take a pointer to any of these 
> elements and modify them (basically modifying the inner *Element pointer).
>
> Currently, I don't think I can abstract over these types which share in 
> common the *Element field and the AsEleemnt method promoted from it.
> I don't want to have to implement a specific method to do that mutation 
> operation for each and every one of these types either.
>
> Basically, trying to make generic this function:
>
> func Ref(vref **Element) func(*Element) *Element{
> return func(e *Element)*Element{
> *vref = e
> return e
> }
> }
>
>
> Or does anyone see something that I missed?
>
> On Thursday, April 4, 2024 at 2:52:16 AM UTC+2 Adam Manwaring wrote:
>
>> While this would make some things much easier for me, it seems this would 
>> be a pretty fundamental change. Constraints are essentially interfaces and 
>> interfaces in Go are defined by behaviors. Structs, on the other hand, are 
>> defined by properties. There is no behavior that all structs have that 
>> every other type couldn't also have. Thus having a struct constraint would 
>> be a one-off exception which for the most part seems anathema to Go. In a 
>> similar vein, there are many times I'd like an interface to require certain 
>> exported properties in addition to behaviors, but this isn't going to 
>> happen.
>>
>> On Wednesday, March 27, 2024 at 6:28:19 PM UTC-6 Makis Maropoulos wrote:
>>
>>> Same here @Abraham, 
>>>
>>> ResponseType interface {
>>> ~struct{}
>>> }
>>>
>>> Obviously this doesn't work, I would love to see it working though.
>>> On Wednesday 14 September 2022 at 17:48:19 UTC+3 Abraham wrote:
>>>
>>>> I am glad I found this thread because I was just now breaking my head 
>>>> figuring out why my  was not working
>>>>
>>>> On Wednesday, May 18, 2022 at 10:41:29 PM UTC-4 Ian Lance Taylor wrote:
>>>>
>>>>> On Wed, May 18, 2022 at 7:36 PM Jeremy Kassis  
>>>>> wrote: 
>>>>> > 
>>>>> > Where exactly did this land? Seems like an important conversation... 
>>>>>
>>>>> To date there is no way to write a constraint that requires that a 
>>>>> type argument be a struct type. 
>>>>>
>>>>>
>>>>> > ``` 
>>>>> > // RPCHandler passes RPCReq and RPCRes as fn args 
>>>>> > func RPCHandler[T RPCReq, S RPCRes](fn func(T, S)) http.HandlerFunc 
>>>>> { 
>>>>> > return func(w http.ResponseWriter, r *http.Request) { 
>>>>> > req := T{} 
>>>>> > if err := reqBodyReadAll(w, r, &req); err != nil { 
>>>>> > resWriteErr(w, err) 
>>>>> > return 
>>>>> > } 
>>>>> > res := S{} 
>>>>> > fn(req, res) 
>>>>> > resWriteAll(w, r, res) 
>>>>> > } 
>>>>> > } 
>>>>> > ``` 
>>>>>
>>>>> I would write simply "var req T" and "var res S". 
>>>>>
>>>>> Ian 
>>>>>
>>>>

-- 
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/c34ebc0f-c2bf-4b59-a59d-ee3b3047bca6n%40googlegroups.com.

Re: [go-nuts] [generics] type constraint for structs

[atd...@gmail.com]

It allows to return the value pointed at (*Element) but I still don't have 
access to the *Element field adddress of let's say var d Div so can't 
change d.Element to swap it with another value. (by taking Ref(&d,e) where 
e is some *Element)

It's usable as a constraint but that's not sufficient.


On Thursday, April 4, 2024 at 6:53:27 AM UTC+2 Axel Wagner wrote:

> How does `interface{ AsElement() *Element }` not do exactly what you want?
>
> On Thu, Apr 4, 2024 at 4:14 AM atd...@gmail.com  wrote:
>
>> Might have come across this today as I was trying to simplify some code.
>>
>> Basically, I have a base type called *Element that has a method 
>> AsElement() *Element that returns itself.
>>
>> And this base element is used as a base for many others, for isntance:
>>
>> type Div struct{ *Element}
>> type Span struct{*Element}
>> type Anchor {*Element}
>> ...
>>
>> Somehow, I need a function Ref that can take a pointer to any of these 
>> elements and modify them (basically modifying the inner *Element pointer).
>>
>> Currently, I don't think I can abstract over these types which share in 
>> common the *Element field and the AsEleemnt method promoted from it.
>> I don't want to have to implement a specific method to do that mutation 
>> operation for each and every one of these types either.
>>
>> Basically, trying to make generic this function:
>>
>> func Ref(vref **Element) func(*Element) *Element{
>> return func(e *Element)*Element{
>> *vref = e
>> return e
>> }
>> }
>>
>>
>> Or does anyone see something that I missed?
>>
>> On Thursday, April 4, 2024 at 2:52:16 AM UTC+2 Adam Manwaring wrote:
>>
>>> While this would make some things much easier for me, it seems this 
>>> would be a pretty fundamental change. Constraints are essentially 
>>> interfaces and interfaces in Go are defined by behaviors. Structs, on the 
>>> other hand, are defined by properties. There is no behavior that all 
>>> structs have that every other type couldn't also have. Thus having a struct 
>>> constraint would be a one-off exception which for the most part seems 
>>> anathema to Go. In a similar vein, there are many times I'd like an 
>>> interface to require certain exported properties in addition to behaviors, 
>>> but this isn't going to happen.
>>>
>>> On Wednesday, March 27, 2024 at 6:28:19 PM UTC-6 Makis Maropoulos wrote:
>>>
>>>> Same here @Abraham, 
>>>>
>>>> ResponseType interface {
>>>> ~struct{}
>>>> }
>>>>
>>>> Obviously this doesn't work, I would love to see it working though.
>>>> On Wednesday 14 September 2022 at 17:48:19 UTC+3 Abraham wrote:
>>>>
>>>>> I am glad I found this thread because I was just now breaking my head 
>>>>> figuring out why my  was not working
>>>>>
>>>>> On Wednesday, May 18, 2022 at 10:41:29 PM UTC-4 Ian Lance Taylor wrote:
>>>>>
>>>>>> On Wed, May 18, 2022 at 7:36 PM Jeremy Kassis  
>>>>>> wrote: 
>>>>>> > 
>>>>>> > Where exactly did this land? Seems like an important 
>>>>>> conversation... 
>>>>>>
>>>>>> To date there is no way to write a constraint that requires that a 
>>>>>> type argument be a struct type. 
>>>>>>
>>>>>>
>>>>>> > ``` 
>>>>>> > // RPCHandler passes RPCReq and RPCRes as fn args 
>>>>>> > func RPCHandler[T RPCReq, S RPCRes](fn func(T, S)) http.HandlerFunc 
>>>>>> { 
>>>>>> > return func(w http.ResponseWriter, r *http.Request) { 
>>>>>> > req := T{} 
>>>>>> > if err := reqBodyReadAll(w, r, &req); err != nil { 
>>>>>> > resWriteErr(w, err) 
>>>>>> > return 
>>>>>> > } 
>>>>>> > res := S{} 
>>>>>> > fn(req, res) 
>>>>>> > resWriteAll(w, r, res) 
>>>>>> > } 
>>>>>> > } 
>>>>>> > ``` 
>>>>>>
>>>>>> I would write simply "var req T" and "var res S". 
>>>>>>
>>>>>> Ian 
>>>>>>
>>>>> -- 
>>
> 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/f2150cf5-75d9-4cb3-9a29-d5a8c8e655a5n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/f2150cf5-75d9-4cb3-9a29-d5a8c8e655a5n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d7c72c15-7223-4a4b-8306-5a83550f19e8n%40googlegroups.com.