> i would value "pure" if it were a contract for early evaluation
does this "early evaluation" concern about IO? like loading blob data with
ioutil.ReadFile into global variable at compile time?
> 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.
Yeah, true, and I'm okay with that.
me alone maybe not enough to justify it, I created this post here to see if
others also need this feature and justify the cost to add it to the
language.
On Tuesday, July 7, 2020 at 7:34:14 AM UTC+7 Ian Lance Taylor wrote:
> 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/992e5074-41bd-4acd-b902-38f1fca0c717n%40googlegroups.com.
