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 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:
"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. 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.
