The problem with determining if a function is pure or not is not just limited to looking for references to external memory and the like, but also has to take into account that the function might contain an infinite loop, for example, and this is difficult because there is no general-purpose algorithm for finding out if a given program (or a group of functions) will finish or continue running forever. See "Turing's halting problem": https://en.wikipedia.org/wiki/Halting_problem As mentioned before, the other reason is semantics. It might potentially confuse the programmer if "const x = FunctionCall(42);" is seemingly allowed for some arbitrary functions, but not others. By clearly defining valid functions as pure, it makes it clear to the programmer what can be specified, and also aids in debugging because the compiler will throw a warning if the function is question is actually impure, for example (and then the actual error for trying to assign a function result to a constant).
Gareth On Mon 09/07/18 00:00 , Dmitry Boyarintsev skalogryz.li...@gmail.com sent: On Sun, Jul 8, 2018 at 6:47 PM, Thorsten Engler wrote: You are thinking about something like: const x = FunctionCall(42); In which case, yes, the compiler could possibly see that as in implicit “check if that function is pure”. But “constant expressions” can also be something like: If FunctionCall(42) > 0 then In which case you don’t want the compiler to have to test every single expression in your program to see if it is composed (all the way down) of pure functions. Maybe a different approach should be taken?Determine how much performance impact is made to determine the purity of a function. and then consider adding a new directive and a keyword. thanks, Dmitry _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [3]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: ------ [1] mailto:thorsten.eng...@gmx.net [2] mailto:fpc-devel@lists.freepascal.org [3] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
