I don't actually prefer marking a func as pure. best if it is a discovered
attribute during compilation.
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. 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.
For more options, visit https://groups.google.com/d/optout.
