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 <[email protected]> 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 <[email protected]>
>> wrote:
>> >>
>> >> On Mon, Jul 6, 2020 at 9:47 AM <[email protected]> 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 [email protected].
>> >> 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 [email protected].
>> > 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 the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/c75305e2-27e4-4a33-9111-d5b1c54eb9c9n%40googlegroups.com.
