<HTML>
<div>Another little progress update with implementing pure functions.</div><div><br>
</div><div>1. In my code (not submitted yet), the compiler now recognises and accepts the 'pure' directive. There are a number of other directives that it can't be used with ('noreturn' being one of them) and it can't be used on object methods.</div><div><br>
</div><div>2. A compiler hint is thrown if a function is not pure, but can definitely be made pure. This is done via a new procinfo flag named "pi_pure_uncertain", which is set if any loops, jumps or calls are encountered, as well as anything that makes the function impure. If the flag is <span style="font-weight: bold;">not</span> set when the function's node tree has been built, then it's definitely a pure function. Note that the compiler won't start treating it as a pure function - it only gives the hint that it could do.</div><div><br>
</div><div>3. A compiler warning is thrown if a function marked as pure tries to access a variable whose scope falls outside of the subroutine (i.e. it's not local). Similar warnings are thrown if the ^ and @ operators are used.<br>
</div><div><br>
</div><div>I haven't programmed in the actual compile-time evaluation yet
because that requires stepping through the nodes like an interpreter. That's my next challenge once I get the initial compilation and validation done.</div><div><br>
</div><div>Some things will take a little bit of thought. With a pure function calling another pure function, it's not always known if the callee is pure at this point (e.g. with a forward declaration and/or where the 'pure' directive only appears in the implementation section), so it will have to come back to check it later somehow, which might be difficult if the original pure function is being called before its own implementation (as part of a constant assignment, for example).<br>
</div><div><br>
</div><div>Though not tested or fully validated yet, it's intended that only floating-point and ordinal type parameters and variables are supported initially for the sake of simplicity. Support for record types and strings will be a bit more complicated and something I'll do later, assuming there's a need for more complex types in pure functions - I can think of examples where they will, such as with "IntToStr" (when called by another pure function) with strings, and a library of routines for handling complex numbers, say (record type consisting of 2 Doubles).<br>
</div><div><br>
</div><div>Hopefully I can present something in the near future to be tested and ripped apart by other developers and SQA!<br>
</div><br>
Gareth aka. Kit<br>
</HTML>