I posted this on the main list before but I want to repost here. Last month I
decided finally after years to try working on the compiler and in short time I
was able to add parameters to macros (like in C). The FPC list appeared to
universally despise this idea so I guess I’ll just sit on it and
> On Jul 8, 2018, at 10:55 AM, Marco van de Voort wrote:
>
> It doesn't explain why you chose for a modifier rather than preprocessor
> switch.
Performance aside I think it’s useful to mark a function as “pure” so you can
guarantee it’s not messing with global state. I’m sure I could have us
> On Jul 8, 2018, at 8:50 AM, J. Gareth Moreton
> wrote:
>
> With some blessing from Florian on the concept, I've set up a Wiki page
> discussing the design proposals for the support of pure functions, as well as
> some explanation on what they actually are.
>
What are the performance bene
I've only really researched and improved the peephole optimizer, which is
the assembler stage. I'm not sure how much optimisation is done at
earlier stages, but I do know that care is taken in deciding the best
implementation of a case block, for example, evaluating factors such as how
many sep
That's something for future research. Initially I just want to get pure
Pascal procedures working, and that's the most important since it's
cross-platform. Analysing assembler routines will require a different
kind of interpretation, and it will likely involve only allowing a certain
subset of o
n Sun, Jul 8, 2018 at 9:07 PM, Dmitry Boyarintsev
wrote:
>
> On Sun, Jul 8, 2018 at 8:15 PM, J. Gareth Moreton
> wrote:
>>
>> Yes, if any parameters are variables, then the function is not evaluated.
>> My intention is that the purity of a function is only determined when it
>> comes to evaluatin
On Sun, Jul 8, 2018 at 8:15 PM, J. Gareth Moreton wrote:
> Yes, if any parameters are variables, then the function is not evaluated.
> My intention is that the purity of a function is only determined when it
> comes to evaluating it in an expression, but because of how complex
> functions can bec
On Sun, Jul 8, 2018 at 9:47 PM, Thorsten Engler
wrote:
>
>
> If the loop is being unrolled, what looks like a non-const expression
> becomes a const expression. So if SomeFunc is marked as pure, the compiler
> might be able to omit the call completely.
>
>
There were some time testing done with C
Thinking about it some more, this might also interact with loop unrolling.
e.g.:
for i := 0 to 9 do
x := x * SomeFunc(i);
If the loop is being unrolled, what looks like a non-const expression becomes a
const expression. So if SomeFunc is marked as pure, the compiler might be able
t
If I had to give a realistic example of a pure function in such a
conditional expression, how about?
"if (decay_constant * time_elapsed) >= ln(2) then ..."
This is a formula related to radioactive decay - if the condition is true,
then over half of the original sample has decayed (i.e. time_el
On Sun, Jul 8, 2018 at 7:18 PM, Thorsten Engler
wrote:
> Maybe you don’t understand what “determine the purity of a function” means?
>
>
>
> It means that every time any function is called, the compiler has to try
> to execute the function at compile time (by working through the nodes like
> an i
The problem with determining if a function is pure or not is not just
limited to looking for references to external memory and the like, but also
has to take into account that the function might contain an infinite loop,
for example, and this is difficult because there is no general-purpose
algori
I've fixed the reference in the Wiki - it now calls "pure" a directive,
not a keyword.
I predict that evaluating the purity of a function to be an expensive
operation and something that should be avoided where possible, especially
when compiling something large like Lazarus or the compiler itsel
Maybe you don’t understand what “determine the purity of a function” means?
It means that every time any function is called, the compiler has to try to
execute the function at compile time (by working through the nodes like an
interpreter) until it hits a point that is non-deterministic. This
On Sun, Jul 8, 2018 at 6:47 PM, Thorsten Engler
wrote:
> You are thinking about something like:
>
>
>
> const
>
> x = FunctionCall(42);
>
>
>
> In which case, yes, the compiler could possibly see that as in implicit
> “check if that function is pure”.
>
>
>
> But “constant expressions” can also
You are thinking about something like:
const
x = FunctionCall(42);
In which case, yes, the compiler could possibly see that as in implicit “check
if that function is pure”.
But “constant expressions” can also be something like:
If FunctionCall(42) > 0 then
In which case you
On Sun, Jul 8, 2018 at 5:43 PM, Thorsten Engler
wrote:
> People keep talking about keywords. As shown in the examples, pure is not
> a keyword. It's a context-sensitive directive. This is already wrongly
> stated in the proposal itself (so people can be excused for picking up on
> the use of the
That's my fault for using the wrong
terminology in that case - feel free to
fix it.
And yes, the directive tells the compiler
that the programmer intends for this
function to be pure. It still requires
effort by the compiler to determine if
it's eligible, because the only way to
figure out
> -Original Message-
> From: fpc-devel On Behalf Of
> R0b0t1
> Sent: Monday, 9 July 2018 07:22
>
> There were some other comments touching on reasons for or against a
> keyword, and I apologize for not speaking to them precisely. But,
> this is why I would like to avoid a keyword - it is
On Sun, Jul 8, 2018 at 12:33 PM, Marco van de Voort wrote:
> In our previous episode, Florian Kl?mpfl said:
>> >
>> > It doesn't explain why you chose for a modifier rather than preprocessor
>> > switch.
>>
>> Why a preprocessor switch for something which applies to a particular
>> function?
>
>
Am 08.07.2018 um 19:33 schrieb Marco van de Voort:
In our previous episode, Florian Kl?mpfl said:
It doesn't explain why you chose for a modifier rather than preprocessor
switch.
Why a preprocessor switch for something which applies to a particular function?
Maybe. But this kind of stuff wi
On Sun, Jul 8, 2018 at 1:01 PM, Florian Klämpfl
wrote:
>
>
> No. Because pure is part of the function header and tells users "you can
> use this function with constant arguments in constant expressions and this
> won't change without notification". If the compiler determines by itself if
> a funct
On 08/07/2018 19:22, J. Gareth Moreton wrote:
At the same time, I would argue that, really, the programmer should
code something like this:
c := sin(x);
if c > y then b := c;
There probably isn't any harm in supporting such optimisation though.
Talking about this Maybe it is worth to al
At the same time, I would argue that, really, the programmer should code
something like this:
c := sin(x);if c > y then b := c;
There probably isn't any harm in supporting such optimisation though.
Gareth
On Sun 08/07/18 18:19 , "J. Gareth Moreton" gar...@moreton-family.com
sent:
The conc
The concept of pure functions is that it allows for their evaluation at
compile time for constant arguments. In your example, function purity
wouldn't play into it because x, I assume, is a variable whose value is
unknown at compile time. However, advanced data flow analysis might be
able to spo
On 08/07/2018 16:50, J. Gareth Moreton wrote:
Hi everyone,
With some blessing from Florian on the concept, I've set up a Wiki
page discussing the design proposals for the support of pure
functions, as well as some explanation on what they actually are.
wiki.freepascal.org/Pure_functions
I h
It's sort of the other way around. The lack of the directive implies the
function is impure, and so the compiler won't bother with any kind of
purity check. The presence of "pure" slows down the compiler, but
possibly producing much more efficient code. Because pure functions will
be rare, it s
In our previous episode, Florian Kl?mpfl said:
> >
> > It doesn't explain why you chose for a modifier rather than preprocessor
> > switch.
>
> Why a preprocessor switch for something which applies to a particular
> function?
Maybe. But this kind of stuff will be rare, and is only an hint to sp
It also feels safer and more intuitive for the programmer. If you're
writing code such as "const Partitions = log2(Length(StaticList));"
(assuming Length(StaticList) evaluates to a constant value), then defining
log2 as a pure function shows you know what you're doing, because otherwise
it might
What Florian said. Only particular functions can be pure, and even if they
are marked as such, the compiler has to make sure they are fulfil a strict
set of criteria that requires a degree of data flow analysis, and this can
quickly take far too long to complete, especially if the function contain
Am 08.07.2018 um 18:53 schrieb Dmitry Boyarintsev:
On Sun, Jul 8, 2018 at 11:20 AM, J. Gareth Moreton mailto:gar...@moreton-family.com>> wrote:
As far as I know, keywords are often used (e.g. "constexpr" in C++). My
reasons are explained in the Wiki topic,
but it boils down to compiler
Am 08.07.2018 um 18:55 schrieb Marco van de Voort:
In our previous episode, J. Gareth Moreton said:
wiki.freepascal.org/Pure_functions
I hope it proves useful to explain what I'm doing. How do the proposals
look so far, Florian?
It doesn't explain why you chose for a modifier rather than p
In our previous episode, J. Gareth Moreton said:
> wiki.freepascal.org/Pure_functions
> I hope it proves useful to explain what I'm doing. How do the proposals
> look so far, Florian?
It doesn't explain why you chose for a modifier rather than preprocessor
switch.
__
On Sun, Jul 8, 2018 at 11:20 AM, J. Gareth Moreton <
gar...@moreton-family.com> wrote:
> As far as I know, keywords are often used (e.g. "constexpr" in C++). My
> reasons are explained in the Wiki topic, but it boils down to compiler
> performance.
>
How about adding a new modeswitch instead PUR
As far as I know, keywords are often used (e.g. "constexpr" in C++). My
reasons are explained in the Wiki topic, but it boils down to compiler
performance. If every function is assumed to be pure, then the compiler
has to check each time if that is actually the case, and with a large
project wit
On Sun, Jul 8, 2018 at 9:50 AM, J. Gareth Moreton
wrote:
> Hi everyone,
>
> With some blessing from Florian on the concept, I've set up a Wiki page
> discussing the design proposals for the support of pure functions, as well
> as some explanation on what they actually are.
>
> wiki.freepascal.org/
Hi everyone,
With some blessing from Florian on the concept, I've set up a Wiki page
discussing the design proposals for the support of pure functions, as well
as some explanation on what they actually are.
wiki.freepascal.org/Pure_functions
I hope it proves useful to explain what I'm doing. H
37 matches
Mail list logo
