[go-nuts] Pure functions and Go2

2018-12-14 Thread Michael Jones
Have been thinking about pure functions (in the Scheme sense of no externalities other than constants and pure functions and no side effects) in the context of weak metaprogramming and compiler optimization. Here is the idea. : a := math.Sin(0.1234) : b := bits.RotateLeft64(0x12345678, 7) : func m

Re: [go-nuts] Pure functions and Go2

2018-12-14 Thread Bakul Shah
On Dec 14, 2018, at 12:50 PM, Michael Jones wrote: > > Have been thinking about pure functions (in the Scheme sense of no > externalities other than constants and pure functions and no side effects) in > the context of weak metaprogramming and compiler optimization. Here is the > idea. Scheme

Re: [go-nuts] Pure functions and Go2

2018-12-14 Thread Michael Jones
I don't actually prefer marking a func as pure. best if it is a discovered attribute during compilation. Not sure what you mean about complexity. The compiler would not be obligated. On Fri, Dec 14, 2018 at 1:12 PM Bakul Shah wrote: > On Dec 14, 2018, at 12:50 PM, Michael Jones > wrote: > > >

Re: [go-nuts] Pure functions and Go2

2018-12-14 Thread Ian Denhardt
Quoting Bakul Shah (2018-12-14 16:11:51) > > If a function was labeled as pure ("pure func ...") the compiler > > would not even need think hard, and if purity were a reflectable > > attribute, then it is imaginable that compiling a function > > invocation could be: > > This would complicate the la

Re: [go-nuts] Pure functions and Go2

2018-12-14 Thread Bakul Shah
> On Dec 14, 2018, at 1:17 PM, Michael Jones wrote: > > I don't actually prefer marking a func as pure. best if it is a discovered > attribute during compilation. You said > If a function was labeled as pure ("pure func ...") the compiler would not > even need think hard I thought you were

Re: [go-nuts] Pure functions and Go2

2018-12-14 Thread Michael Jones
I can't deny proposing it, but i'd much rather it be inferred...if fo no other reason than because the developer could be wrong and that would be an insidious flaw to debug. I proposed it defensively so that the initial reactions might not all be that it is to recognize purity as it was for Diogen

Re: [go-nuts] Pure functions and Go2

2018-12-14 Thread 'Axel Wagner' via golang-nuts
On Fri, Dec 14, 2018 at 9:51 PM Michael Jones wrote: > There is no absolute reason why a, b, and c could not be evaluated at > compile time. > Being pure is not enough for that. You need at least pure and total - otherwise you could have pure func Foo(x int) int { for {} return x } How

Re: [go-nuts] Pure functions and Go2

2018-12-16 Thread Matt Harden
In my opinion, it's even more useful to the programmer to know that a function is pure, than it is to the compiler. If checked by the compiler, the annotation is also useful to ensure that the function remains pure as it is modified over time. On Fri, Dec 14, 2018 at 2:57 PM 'Axel Wagner' via gola