[fpc-devel] pure function feedback

[Hairy Pixels]

I had a question about pure functions. I'm seeing some newer languages have a JIT built-in so they can run any function at compile time. To get results at compile time you probably need to use a constant for the parameters but in theory it could read/write to global variables so it's not really "pure" but still makes it possible to run functions at compile time.

How does this compare to pure functions? It seems like the JIT is actually easier to implement than all this complicated node analysis, but probably slower to run I may guess. I think the LLVM backend could do this but the main code generator I'm not sure.

> On Jun 30, 2024, at 9:17 AM, J. Gareth Moreton via fpc-devel <fpc-devel at lists.freepascal.org> wrote:
> 
> Fixed 2 and 3.
> - 2 was due to not handling block nodes properly when they didn't have any statements (data-flow analysis stripped the procedure completely clean since no result was set), hence an access violation occurred while accessing a node that was nil.
> - 3 was a two-fold problem:
>     • The functiuon being ineligible was because a typeconv node couldn't be stripped out and so the final assignment tree wasn't in an expected format.  The analysis code now specifically permits this form of type conversion (convtype = tc_equal and identical resultdefs between the typeconv and the load nodes).
>     • The second problem was due to a small hack where implicit Result parameters were converted from var to out so data-flow analysis worked properly, but they weren't converted back to var parameters afterwards, causing an access violation elsewhere in the code.
> Merge request has been updated - I have also added two new tests based on your examples.  Thanks again Marģers.
> Kit
> On 28/06/2024 13:24, J. Gareth Moreton via fpc-devel wrote:
>> Hi Marģers, 
>> 
>> Thanks for the feedback! 
>> 
>> Assigning the results of pure functions to constants has not yet been developed.  I had planned to add it once the bulk of pure functions (i.e. the current merge request) had been approved since it requires some additional work (specifically what happens if the function is not actually pure or otherwise can't return a straightforward result). 
>> 
>> 2 and 3 are definite bugs though.  The second case should at the very least make the function impure, while the third case should indeed not disqualify the function.  I'll see what I can do. Thanks again. 
>> 
>> Kit 
>> 
>> On 28/06/2024 09:35, Marģers . via fpc-devel wrote:
>>> 1. pure function value to constants 
>>> 
>>> function foo(i:longword):longword; pure; 
>>> begin 
>>>   foo:=9; 
>>> end; 
>>> 
>>> const bar = foo( 8 );  //-- not allowed.. but i expect this to work! 
>>>          jar : longword = foo( 7 ); //-- and this as well 
>>> 
>>> 
>>> 2. this does not end grasefully 
>>> 
>>> function foo (i:longword):shortstring; pure; 
>>> var s : shortstring; 
>>>       n : longword; 
>>> begin 
>>>   s:='''; 
>>>   for n:=1 to i do s:=s +'a'; 
>>>   //-- not assing return value 
>>> end; 
>>> begin writeln(foo(9)); end. 
>>> 
>>> 3. 
>>> function foo (i:longword):ansistring; pure; 
>>> var s : shortstring; 
>>>       n : longword; 
>>> begin 
>>>   s:='''; 
>>>   for n:=1 to i do s:=s +'a'; 
>>>   foo:=s; //-- this makes function not pure, but why whould it! 
>>> end; 
>>> begin writeln(foo(9)); end. 
>>> 
>>> 
>>> _______________________________________________ 
>>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org 
>>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>> 
> 
> Virus-free.www.avast.com _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Regards,
Ryan Joseph