> On Dec 14, 2018, at 1:17 PM, Michael Jones <michael.jo...@gmail.com> wrote:
>
> I don't actually prefer marking a func as pure. best if it is a discovered
> attribute during compilation.
You said
> If a function was labeled as pure ("pure func ...") the compiler would not
> even need think hard
I thought you were advocating this. Compilers can already discover
non-mutating functions with some analysis. But the more such tricks a
compiler discovers, the slower it becomes.... So there is some value
in helping the compiler by marking functions as pure but I think the
cost of doing so is language complexity that a user has to face.
Personally I'd rather see Go become a better higher level language.
>
> Not sure what you mean about complexity. The compiler would not be obligated.
>
>
> On Fri, Dec 14, 2018 at 1:12 PM Bakul Shah <ba...@bitblocks.com> wrote:
> On Dec 14, 2018, at 12:50 PM, Michael Jones <michael.jo...@gmail.com> wrote:
> >
> > Have been thinking about pure functions (in the Scheme sense of no
> > externalities other than constants and pure functions and no side effects)
> > in the context of weak metaprogramming and compiler optimization. Here is
> > the idea.
>
> Scheme does permit impure functions. Such functions by *convention* have
> a "!" suffix but there is nothing special about that.
>
> > :
> > a := math.Sin(0.1234)
> > :
> > b := bits.RotateLeft64(0x12345678, 7)
> > :
> > func myFunc(x int) byte { return x>>2 }
> > :
> > c := myFunc(42):
> >
> > There is no absolute reason why a, b, and c could not be evaluated at
> > compile time.
> >
> > There are many practical reasons why it cannot be done today.
> >
> > If a function was labeled as pure ("pure func ...") the compiler would not
> > even need think hard, and if purity were a reflectable attribute, then it
> > is imaginable that compiling a function invocation could be:
>
> This would complicate the language unnecessarily in the name
> of optimization. Next on the slipper slope would be declaring
> parameters "pure" and then having two versions of things. e.g.
>
> func intReduce(func(x, y int)int, []int) int
>
> This can be evaluated at compile time if the given func is pure.
> Not worth it, IMHO.
>
> >
> > "if package is a standard one (like math) and the function is a pure one,
> > then call func on argument and use the result here"
> >
> > Doing this for user packages brings up deeper issues and is harder.
> >
> > --
> > Michael T. Jones
> > 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.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Michael T. Jones
> 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.
> For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
