> the name "pure" may be debatable, but the characteristic is the same with "constexpr" in C++, although I also don't have a strong reason why this is important beside separation IO and non-IO
D is a lange that has true pure functions, see https://dlang.org/spec/function.html#pure-functions While D is a very feature rich and elaborate language Go is made with simplicity as the driving design criteria in mind. If you want very elaborate things like pure functions Go might be the wrong language choice as in Go things will continue to strive for simplicity. Ian Lance Taylor schrieb am Dienstag, 7. Juli 2020 um 02:34:14 UTC+2: > On Mon, Jul 6, 2020 at 5:11 PM Kurniagusta Dwinto > <kurnia...@gmail.com> wrote: > > > > > It's not obvious to me that "pure" is a characteristic that is > important enough > > > to be singled out and added to the language > > > > the name "pure" may be debatable, but the characteristic is the same > with "constexpr" in C++, although I also don't have a strong reason why > this is important beside separation IO and non-IO > > Well, C++ is a very different language with very different goals. I > think history shows that C++ is much more comfortable adding new > features than Go is. > > Ian > > > > On Tue, Jul 7, 2020 at 7:05 AM Kurniagusta Dwinto <kurnia...@gmail.com> > wrote: > >> > >> Additionally, this feature complement new generic feature, > >> this feature will help anyone that trying to use functional programming > pattern (like monad pattern) in their code > >> > >> On Tuesday, July 7, 2020 at 6:52:31 AM UTC+7 Kurniagusta Dwinto wrote: > >>> > >>> Adding pure marker will give information to the programmer that the > function will not do any side effect, the compiler just gives compile error > when the programmer disagrees about the contract, like doing IO operation > on pure function. > >>> So in the end, this feature focuses on helping the programmer, not the > compiler, to make sure the function does not do any io operation inside it. > >>> I like how Haskell separate IO and non-IO function, they create a > clear separation between those worlds, > >>> > >>> On the other side, the compiler can evaluate some function in > compile-time, although this feature maybe not really needed yet, this will > help the programmer to create pre-computed value instead of copying some > magic blob data, > >>> > >>> > >>> > I agree that adding the keyword would let the compiler enforce it, > but > >>> > that doesn't seem all that big a benefit to me. It also seems like > >>> > something that could be done by an analysis tool rather than > requiring > >>> > a change to the language. > >>> > >>> That wouldn't work with interfaces, like > >>> > >>> purefunc Hai(x interface{}) int { > >>> val := 42 > >>> if x, ok := x.(interface { pure Value() int }); ok { > >>> val += x.Value() > >>> } > >>> return val > >>> } > >>> > >>> here, without knowing the implementation, the caller of Hai know that > Hai will not do any IO operation at all. > >>> > >>> I've tried to create an analysis tool to do that before. I need to > mark the pure function with "Pure" suffix, > >>> the code above will be > >>> > >>> func HaiPure(x interface{}) int { > >>> val := 42 > >>> if x, ok := x.(interface { ValuePure() int }); ok { > >>> val += x.ValuePure() > >>> } > >>> return val > >>> } > >>> > >>> But when it comes to passing a function as a parameter, it will become > more subtle > >>> > >>> purefunc Hai(x purefunc() int) int { > >>> return 42 + x() > >>> } > >>> > >>> // this should generate a compile error > >>> a := 20 > >>> fmt.Println(Hai(purefunc() int { > >>> a += 1 // side effect > >>> fmt.Println("something") // side effect > >>> return a > >>> })) > >>> On Tuesday, July 7, 2020 at 5:56:23 AM UTC+7 Ian Lance Taylor wrote: > >>>> > >>>> On Mon, Jul 6, 2020 at 3:11 PM bugpowder <mit...@gmail.com> wrote: > >>>> > > >>>> > I'd guess the compiler could then enforce it (see if any non-pure > marked function is called from a pure one), it could exploit it (e.g. play > with evaluation order, cache, etc), and other such things? > >>>> > >>>> The compiler can already tell whether a function is pure, so I don't > >>>> think that adding a keyword would lead to any better optimization. > >>>> > >>>> I agree that adding the keyword would let the compiler enforce it, but > >>>> that doesn't seem all that big a benefit to me. It also seems like > >>>> something that could be done by an analysis tool rather than requiring > >>>> a change to the language. > >>>> > >>>> Ian > >>>> > >>>> > >>>> > On Tue, Jul 7, 2020 at 1:00 AM Ian Lance Taylor <ia...@golang.org> > wrote: > >>>> >> > >>>> >> On Mon, Jul 6, 2020 at 9:47 AM <kurnia...@gmail.com> wrote: > >>>> >> > > >>>> >> > Hi, I don't know if this kind of idea is already discussed > before. > >>>> >> > > >>>> >> > I have an idea of adding pure function marker/type on golang, it > is just like "constexpr" on C++ or "const fn" on Rust, whether this > function is evaluated at compile time if the input is known at compile time > is another discussion, > >>>> >> > I don't think this idea is hard to implement > >>>> >> > > >>>> >> > to my understanding, a pure function is a function that doesn't > have a side effect, so we can limit pure function to: > >>>> >> > - unable to call non-pure function > >>>> >> > - unable to modify a variable that is not declared on current > function (like a global variable) > >>>> >> > > >>>> >> > for this purpose, we can think receiver as input to the function > >>>> >> > >>>> >> ... > >>>> >> > >>>> >> > what do you guys think about this idea? > >>>> >> > >>>> >> You didn't really explain what we would gain by adding this to the > >>>> >> language. It's clearly already possible to write pure functions. > How > >>>> >> does it help to add the ability to explicitly mark a function as > pure? > >>>> >> > >>>> >> 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/CAOyqgcXOdCc8Zz8mXAmghLm%2B6%3Dvi8S8zG_3Phrv2Hy-w%3Dm70kQ%40mail.gmail.com > . > >>>> > > >>>> > -- > >>>> > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > >>>> > To unsubscribe from this group and stop receiving emails from it, > send an email to golang-nuts...@googlegroups.com. > >>>> > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAACdnTAKTKQxU_K5xRqHGDKKBEhyTAq6%3D6q1HK%2BgDUewgJW1aw%40mail.gmail.com > . > >> > >> -- > >> 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/RfruW8qemOg/unsubscribe. > >> To unsubscribe from this group and all its topics, send an email to > golang-nuts...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/c75305e2-27e4-4a33-9111-d5b1c54eb9c9n%40googlegroups.com > . > > > > > > > > -- > > Regards, > > Kurniagusta Dwinto > > Fakultas Ilmu Komputer, Universitas Indonesia > > > > -- > > 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/CAEz1khoDwcKXdieicdSgXGQ8ruwKw4m3FCh8sSkTVoOcOqb2SA%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3c67ad7c-1fd6-44d4-a538-acfc34ba28f0n%40googlegroups.com.
