[fpc-devel] Pure function development

J. Gareth Moreton gareth at moreton-family.com
Wed Apr 29 13:41:27 CEST 2020

Hi Sven,

Thanks for the response.  Yes, this is all inside the compiler. 
Basically I need a means to keep track of the internal state of a 
function as I step through the nodes (a process I call 'node 
emulation'), namely local variables, parameters (if they're not const, 
they're basically just like local variables), and the function Result 
and out parameters.  Since these may be all sorts of things like 
integers, floating-point values, strings or record types, I need a 
system that can handle all of these value types. I figure the compiler 
has an existing structure somewhere, but I'm not sure what it is.

The other use of such a structure for handling these values is to store 
the results of the emulation, so as to save time.  If you had the 
following pure function (I'm aware it's not the most efficient 
implementation of the factorial operation):

function Factorial(n: Cardinal): Cardinal; pure;
   if (n <= 1) then
     Result := n * Factorial(n - 1);

(I'm using "Exit(1)" so I have a different set of nodes to test)

Say you calculate Factorial(4) - you get a result of 24.  Later on, you 
may want to calculate Factorial(5), but when it reaches the recursive 
call, it can look up Factorial(4) to see it has already calculated that 
to be 24, and so simply recall that value instead of going through the 
whole process again and hence obtain the answer of 120 far faster.  It's 
the main argument I have against making all functions pure until proven 
otherwise... it would take the compiler a long time to determine if the 
function actually is pure etc (especially if you do something malicious 
like program an infinite loop).

The above function is quite simple, since I only need to track "n" and 
"Result", both Cardinals, but there may be cases where I need to track 
strings (e.g. "IntToStr" / "tostr" could be pure functions, which would 
allow for further optimisations as it means other pure functions are 
permitted to call them).

Gareth aka. Kit

On 29/04/2020 06:42, Sven Barth via fpc-devel wrote:
> Am 29.04.2020 um 00:31 schrieb J. Gareth Moreton:
>> Hi everyone,
>> I'm having a serious bash at developing pure functions for FPC now, 
>> specifically 'node emulation' so it can step through a pure function 
>> and compute output values.  One of the small problems I'm trying to 
>> solve is keeping track of the state of variables, some of which are 
>> record types or otherwise non-standard (e.g. _m128). Just before I 
>> develop something that isn't cross-platform, is it acceptable to use 
>> GetMem (and the use of pointers) and TVarRec on all platforms? (note 
>> I'm using TVarRec, not the Variant type).
> As I assume you mean inside the compiler, then yes, those are features 
> that can be considered available on systems the compiler works on. 
> Though you'll have to check whether TVarRec is the right choice for 
> you (no, definitely not Variant!), because due to Delphi compatibility 
> it does not contain a LongWord field. Maybe instead you'll want to use 
> something like TConstValue or some new record that contains the 
> necessary information? How do you plan to use it, that might give 
> enough hints to decide what to do?
> Regards,
> Sven
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

This email has been checked for viruses by Avast antivirus software.

More information about the fpc-devel mailing list