On Mon, Jul 6, 2020 at 5:11 PM Kurniagusta Dwinto
<kurnia.d....@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.d....@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+unsubscr...@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+unsubscr...@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/CAOyqgcWjup%2B-cZA33-op4fuks2ZUXeUBrEWR3n-8-2XPCgAdVg%40mail.gmail.com.
