I can't deny proposing it, but i'd much rather it be inferred...if fo no
other reason than because the developer could be wrong and that would be an
insidious flaw to debug.
I proposed it defensively so that the initial reactions might not all be
that it is to recognize purity as it was for Diogenes to find an honest man.
On Fri, Dec 14, 2018 at 1:28 PM Bakul Shah <ba...@bitblocks.com> wrote:
>
>
> > 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.
>
>
--
*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.
