On Wed, Feb 21, 2024 at 1:36 AM Sam Vilain <s...@vilain.net> wrote:
> I had a brief look on the Golang issues in Github and could not find any > prior proposals along this line using "context" and "dynamic scope" as > search terms, so I'll submit this as a "new" proposal for now > FWIW some prior discussion on this list: https://groups.google.com/g/golang-nuts/c/bwJecP42Olk https://groups.google.com/g/golang-nuts/c/8v1aSKMxIuo https://groups.google.com/g/golang-nuts/c/eEDlXAVW9vU (we both participated in it, so I assume you're aware of this one) > Thanks again, and truly—thanks for responding, >100% better than people > who just rolled eyes and marked thread as read. > > Cheers, > Sam > On 2/20/24 3:35 PM, Axel Wagner wrote: > > If I may quote myself: > > > And no matter which choice you make for the language - it means that if > the programmers wanted the other, they'd have to jump through annoying > hoops and get confusing and hard to debug problems. > > Having a mechanism to get one or the other semantic doesn't change the > fact that it's easy to choose wrongly by accident, as long as the effect is > implicit. In fact, the mechanism you propose (AIUI) seems extra confusing: > Having a function value sometimes create a new dynamic scope and sometimes > not, is weird and seems like a recipe for frustration. > > But really, convincing me isn't really the point, which is why I'm not > super invested in litigating this (otherwise I might try to come up with > realistic examples, for instance. Or explain further why I'm still not sure > that this can be implemented efficiently). I'm just re-stating what, in the > past, where the reasons why things like this have been rejected. In order > to predict what I would consider a likely outcome of a proposal like this. > > If you think I am wrong or misunderstanding you, you can always file a > proposal to get a more official response. > > On Tue, Feb 20, 2024 at 8:18 PM Sam Vilain <s...@vilain.net> wrote: > >> On 2/17/24 1:32 AM, Axel Wagner wrote: >> >> On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain <s...@vilain.net> wrote: >> >>> I would argue that the matter can be simply decided by choosing the >>> *calling* stack, not the destination stack. >>> >> >> I agree that this is *one choice*. But the point is, that *sometimes* >> you'd want one and *sometimes* the other. And no matter which choice you >> make for the language - it means that if the programmers wanted the other, >> they'd have to jump through annoying hoops and get confusing and hard to >> debug problems. So if you want to justify either choice, you have to make >> an argument that it is so overwhelmingly more common what people would >> want, that the cost of running into these problems is small enough to be >> justified by the benefit. >> >> I think that's a hard case to make. >> >> Alex, I agree that there are cases where you might prefer one versus the >> other. However, you cut out the part of my reply where I pointed out it >> was possible to choose semantics by either returning a closure (context is >> the source stack) or a bound method (context is the destination stack). >> Both of these values can be used interchangeably, as they have the same >> type, func ..., and so the caller does not need to care whether the >> function they are calling uses the calling context or the original >> context. Were you not convinced by the argument? >> >> Sam >> > -- > Sam > > -- 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/CAEkBMfEMGd%3DHmm0Cd%3DaDoHtq79jTbD0r6OUF1KeQ-e3ebABZZA%40mail.gmail.com.
