Re: [go-nuts] pure function on golang

[Kurniagusta Dwinto]

Hello guys, thanks for the response, 
After brainstorming for a while, I think we can implement this without 
changes in the language, and create static analysis tools for it,
What's wrong with my approach before is using the suffix "Pure" as a pure 
function marker, which is unreliable because the function name is not part 
of the function signature.
So to mark a function is pure, we need to embed the pure marker into the 
function signature, so it's impossible to lose this information,
then, the next observation is pure function must return something, there is 
no point of having a pure function that returns nothing.
With these facts and generic feature in the next golang, We can create a 
new type in a new package

// pure.go
package pure
type Value (type T) struct { Value T }

then to mark a function pure, we can use it like this:

func Sum(data []int) pure.Value(int) {
  total := 0
  for _, x := range data {
total += x
  }
  return pure.Value{total}
}

the rest is the job for a static analysis tool to analyze that the purity 
contract is hold

This will also solve my problem about using a pure function in interface 
type as I state above

On Wednesday, July 8, 2020 at 3:37:07 PM UTC+7 jesper.lou...@gmail.com 
wrote:

> On Mon, Jul 6, 2020 at 6:46 PM  wrote:
>
>>
>> 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)
>>
>>
> You also need an additional property, namely that the function always 
> returns the same output for a given input. That is, it is a "stable" 
> relation from inputs to outputs. Consider e.g.
>
> https://play.golang.org/p/XI4IgfiLoub
>
> where we read a global variable as part of the function body. You could 
> make this into an escaping variable in a closure if you want something more 
> local, but the global will serve the same purpose. There are many variants 
> of this scheme, for instance by reading on a channel as part of the 
> function body, and having that channel fed random values, etc.
>
> Marking an expression as pure is a nominal type of language construction. 
> Go usually prefers structural language constructions in most places, so I 
> don't think it fits into the language design as a whole.
>
>

-- 
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/3afeb6b8-848c-491d-9d3d-1a89ca9d2e04n%40googlegroups.com.

Re: [go-nuts] pure function on golang

[Jesper Louis Andersen]

On Mon, Jul 6, 2020 at 6:46 PM  wrote:

>
> 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)
>
>
You also need an additional property, namely that the function always
returns the same output for a given input. That is, it is a "stable"
relation from inputs to outputs. Consider e.g.

https://play.golang.org/p/XI4IgfiLoub

where we read a global variable as part of the function body. You could
make this into an escaping variable in a closure if you want something more
local, but the global will serve the same purpose. There are many variants
of this scheme, for instance by reading on a channel as part of the
function body, and having that channel fed random values, etc.

Marking an expression as pure is a nominal type of language construction.
Go usually prefers structural language constructions in most places, so I
don't think it fits into the language design as a whole.

-- 
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/CAGrdgiUj339ySGiG5L2aE7jrV4OfhDr%2BW73%2B%2B4w49VG%2BrLFUNw%40mail.gmail.com.

Re: [go-nuts] pure function on golang

[Haddock]

 > 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 

D is a lange that has true pure functions, see 
https://dlang.org/spec/function.html#pure-functions 

While D is a very feature rich and elaborate language Go is made with 
simplicity as the driving design criteria in mind. If you want very 
elaborate things like pure functions Go might be the wrong language choice 
as in Go things will continue to strive for simplicity. 

Ian Lance Taylor schrieb am Dienstag, 7. Juli 2020 um 02:34:14 UTC+2:

> On Mon, Jul 6, 2020 at 5:11 PM Kurniagusta Dwinto
>  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  
> 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  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  
> wrote:
>  >>
>  >> On Mon, Jul 6, 2020 at 9:47 AM  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 

Re: [go-nuts] pure function on golang

[Michael Jones]

The standard math library is a natural, easy gateway; a simple preprocessor
could do it. maybe i'll prototype  it.

On Tue, Jul 7, 2020 at 4:43 AM Brian Candler  wrote:

> On Tuesday, 7 July 2020 01:46:48 UTC+1, Kurniagusta Dwinto wrote:
>>
>> > 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?
>>
>
> I think by definition, any function which accesses the filesystem is not
> pure, since it depends on external state (the state of the filesystem).
>
> --
> 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/94ca32bc-bc07-4ca5-93ef-57a4d7327387o%40googlegroups.com
> 
> .
>


-- 

*Michael T. jonesmichael.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/CALoEmQxpwpbJE1SZ4hV_7EKTGBEaH%3DFHLs4xKQmVft4ddxuBdA%40mail.gmail.com.

Re: [go-nuts] pure function on golang

[Brian Candler]

On Tuesday, 7 July 2020 01:46:48 UTC+1, Kurniagusta Dwinto wrote:
>
> > 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?
>

I think by definition, any function which accesses the filesystem is not 
pure, since it depends on external state (the state of the filesystem).

-- 
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/94ca32bc-bc07-4ca5-93ef-57a4d7327387o%40googlegroups.com.

Re: [go-nuts] pure function on golang

[Kurniagusta Dwinto]

> 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
>  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  
> 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  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  
> wrote:
>  >>
>  >> On Mon, Jul 6, 2020 at 9:47 AM  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 

Re: [go-nuts] pure function on golang

[Ian Lance Taylor]

On Mon, Jul 6, 2020 at 5:11 PM Kurniagusta Dwinto
 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  
> 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  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  wrote:
 >>
 >> On Mon, Jul 6, 2020 at 9:47 AM  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 

Re: [go-nuts] pure function on golang

[Michael Jones]

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 
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 
> 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  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 
 wrote:
 >>
 >> On Mon, Jul 6, 2020 at 9:47 AM  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
 

Re: [go-nuts] pure function on golang

[Kurniagusta Dwinto]

> 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 
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  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 
>>> wrote:
>>> >>
>>> >> On Mon, Jul 6, 2020 at 9:47 AM  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
>>> 

Re: [go-nuts] pure function on golang

[Ian Lance Taylor]

On Mon, Jul 6, 2020 at 4:52 PM 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
> }))


Fair point about interfaces.

There are many many different attributes we could apply to functions
in Go.  For example, one that is commonly requested is "this
function/method does not modify memory via this pointer," which in C
or C++ is implemented using the "const" type qualifier.  It's not
obvious to me that "pure" is a characteristic that is important enough
to be singled out and added to the language.  I suppose it might be
useful in some cases, but the test for whether something is worth
adding to the language is whether the benefit is worth the cost.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXXGttU4kyiNhuMQvHwNX%2B2i8kCx9HNejPv%2BT2UHWkziQ%40mail.gmail.com.

Re: [go-nuts] pure function on golang

[Kurniagusta Dwinto]

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  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  
>> wrote: 
>> >> 
>> >> On Mon, Jul 6, 2020 at 9:47 AM  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 
>> 

Re: [go-nuts] pure function on golang

[Kurniagusta Dwinto]

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  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  
> wrote:
> >>
> >> On Mon, Jul 6, 2020 at 9:47 AM  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 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/a09a6843-c5dc-4da0-89ed-9499841ea0b4n%40googlegroups.com.

Re: [go-nuts] pure function on golang

[Ian Lance Taylor]

On Mon, Jul 6, 2020 at 3:11 PM bugpowder  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  wrote:
>>
>> On Mon, Jul 6, 2020 at 9:47 AM  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+unsubscr...@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+unsubscr...@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 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/CAOyqgcWqYsBB6cWtGaqBrwEomv%2BVbOTTw0pWdzEZxDoqiwvrOw%40mail.gmail.com.

Re: [go-nuts] pure function on golang

[Michael Jones]

prior discussion:
https://groups.google.com/forum/#!searchin/Golang-Nuts/pure$20functions/golang-nuts/ZVeMxBBVpa4/slidZL9KBAAJ

On Mon, Jul 6, 2020 at 3:11 PM bugpowder  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?
>
> On Tue, Jul 7, 2020 at 1:00 AM Ian Lance Taylor  wrote:
>
>> On Mon, Jul 6, 2020 at 9:47 AM  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+unsubscr...@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+unsubscr...@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
> 
> .
>


-- 

*Michael T. jonesmichael.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/CALoEmQxmwWTgOSXdzpS%3DpF3KH65xRULhfTDPePc%2BYnzc-KNmgQ%40mail.gmail.com.

Re: [go-nuts] pure function on golang

[bugpowder]

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?

On Tue, Jul 7, 2020 at 1:00 AM Ian Lance Taylor  wrote:

> On Mon, Jul 6, 2020 at 9:47 AM  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+unsubscr...@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+unsubscr...@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.

Re: [go-nuts] pure function on golang

[Ian Lance Taylor]

On Mon, Jul 6, 2020 at 9:47 AM  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+unsubscr...@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.