In my opinion, it's even more useful to the programmer to know that a
function is pure, than it is to the compiler. If checked by the compiler,
the annotation is also useful to ensure that the function remains pure as
it is modified over time.
On Fri, Dec 14, 2018 at 2:57 PM 'Axel Wagner' via gola
On Fri, Dec 14, 2018 at 9:51 PM Michael Jones
wrote:
> There is no absolute reason why a, b, and c could not be evaluated at
> compile time.
>
Being pure is not enough for that. You need at least pure and total -
otherwise you could have
pure func Foo(x int) int {
for {}
return x
}
How
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 Diogen
> On Dec 14, 2018, at 1:17 PM, Michael Jones 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
Quoting Bakul Shah (2018-12-14 16:11:51)
> > 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 la
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 wrote:
> On Dec 14, 2018, at 12:50 PM, Michael Jones
> wrote:
> >
>
On Dec 14, 2018, at 12:50 PM, Michael Jones 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
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.
:
a := math.Sin(0.1234)
:
b := bits.RotateLeft64(0x12345678, 7)
:
func m