> 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
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
> <https://groups.google.com/d/msgid/golang-nuts/c75305e2-27e4-4a33-9111-d5b1c54eb9c9n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
