[fpc-devel] Return to pure functions!
Sven Barth
pascaldragon at googlemail.com
Thu Sep 19 21:30:28 CEST 2019
Am 19.09.2019 um 20:25 schrieb J. Gareth Moreton:
> One thing I've fallen foul of is how to track variables in what will
> become the 'node parser' that the compiler will use to evaluate pure
> functions to calculate their return values. Because a variable can be
> anything, I was planning on using the Variant type, mainly because it
> contains a union that has everything I need in terms of recording what
> type a variable is and how its value is stored, and I would only end
> up duplicating that. However, the bootstrapper can't find the
> 'variants' unit. Given that no other part of the compiler uses the
> Variant type, is there a rule against using it, or a way to help Make
> find the 'variants' unit?
Only units in the rtl directory can be used. While in theory the
Variants unit could be moved from packages/rtl-objpas back to rtl I
doubt that it is desired to have that behemoth used inside the compiler.
If you need something better use TVarRec instead, it's what is backing
"array of const" and is available in the System unit.
> Submitting everything at once at the end may not be the best approach
> for this, as I or others might find future optimisations for pure
> functions later on (like ascending a pure function call outside of a
> for-loop if it doesn't depend on the loop counter, so it is only
> called once and its return value referenced as needed later on). My
> thought on a first patch is to have the compiler at least recognise
> the 'pure' directive even if it doesn't yet do anything. Is that
> permissible?
In my opinion the first part that's integrating should be something
that's already working. Just parsing a dirctive is not something I
consider "working" (which is also why I'm no fan of parsing, but
ignoring the "delayed" directive for delay loading), especially as we'd
want to get a feeling for the feature and its uses. Thus as a first step
I'd suggest at least simple functions without variables and loops.
Regards,
Sven
More information about the fpc-devel
mailing list