[fpc-devel] Pure function development

[Jonas Maebe]

On 02/05/2020 20:27, J. Gareth Moreton wrote:
> Well, as I've found, there is no straightforward method to actually
> determine if a function is pure or not.  For example, if it stumbles
> upon a procedural call, which may be itself (recursion), it doesn't
> immediately know if that call is to a procedure that is itself pure or
> not.

Generally, the way to deal with recursion is to start by assuming it is
in fact pure (or whatever property you are checking). If it is still
considered pure once you processed it entirely, then the property holds.

> There are also problems if calculating the value of a pure
> function may raise an exception (either by explicitly calling 'raise' or
> doing an integer division by zero, for example),

A function that explicitly raises an exception can never be pure, since
an exception changes global state and there is no way to know what
raising this particular exception means (e.g., it could a hack to return
a value several levels up the stack, or to implement an interprocedural
goto). It might indeed not raise an exception for particular inputs, but
that is no different from a function that e.g. does not read from or
write to any global data for certain inputs.

Implicit exceptions, i.e. run time errors, are different. In that case
you will get a compile-time warning or error similar as during normal
constant evaluation, depending on the active switches like range checking.

> something that breaks
> things down when assigning pure function results to constant
> definitions.  And let's not get started if the pure function contains a
> deliberate infinite loop!

This requires limiting the number of evaluation steps/iterations.


Jonas