i would value "pure" if it were a contract for early evaluation. in my post
on this from 2018 (linked above), the reasoning was so that "x :=
math.Sin(0.23)" would be a compile-time event.
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
>
> 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
> <https://groups.google.com/d/msgid/golang-nuts/CAEz1khoDwcKXdieicdSgXGQ8ruwKw4m3FCh8sSkTVoOcOqb2SA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@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/CALoEmQx%3DVeFVuqw_2-kZufTmQsNx7pWfU6V7z4GXNHWMi5ovJQ%40mail.gmail.com.
