Behalf Of J. Gareth
Moreton
Sent: Wednesday, June 26, 2019 1:20 PM
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] XML node dump feature
https://en.wikipedia.org/wiki/Pure_function
In essence, a pure function will always return the same output for a given
input, analogous to a mathematic
On Wed, Jun 26, 2019 at 1:48 AM J. Gareth Moreton
wrote:
> Maybe I'm misreading this, but does that mean you're not a fan of the
> "pure" directive, Jonas?
>
It seems like if anything, he may have misunderstood that in this context,
"in the hands of the user" is not intended to mean that people
https://en.wikipedia.org/wiki/Pure_function
In essence, a pure function will always return the same output for a
given input, analogous to a mathematical function.
Gareth aka. Kit
On 26/06/2019 12:18, wkitt...@windstream.net wrote:
On 6/26/19 1:48 AM, J. Gareth Moreton wrote:
Maybe I'm
On 6/26/19 1:48 AM, J. Gareth Moreton wrote:
Maybe I'm misreading this, but does that mean you're not a fan of the "pure"
directive, Jonas?
i've been quietly reading along on all this "pure function" stuff since it was
first brought up but somehow i've missed exactly what "pure" means...
Maybe I'm misreading this, but does that mean you're not a fan of the
"pure" directive, Jonas?
My reasoning for including it as a directive and it not being automatic
is that having the compiler determine if a function is pure or not is
going to be an expensive operation and will also
On Tue, Jun 25, 2019 at 12:28 AM Marģers . via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> Sorry to say but, this should not work even with
> *pure* function. Typed constants are not truly
> constants.
>
It's no different at all from doing something like this, which does work,
On Tue, Jun 25, 2019 at 3:23 PM denisgolovan wrote:
> e.g. what about returning dynamic arrays? Like:
>
> type TIntArray = array of Integer;
> function ArrInit(): TIntArray;
> begin
> SetLength(Result, 1);
> Result[0]:=1;
> end;
>
Stuff like that is pretty much impossible, because you can't
On 25/06/2019 21:23, denisgolovan wrote:
>> Complex types are built from primitive types. And if FPC can verify the
>> "pure" attribute is valid, then LLVM can probably also come up with it.
>> In fact, if FPC can verify it is valid, it can also come up with it
>> itself and add it as an
> Complex types are built from primitive types. And if FPC can verify the
> "pure" attribute is valid, then LLVM can probably also come up with it.
> In fact, if FPC can verify it is valid, it can also come up with it
> itself and add it as an annotation in the LLVM bitcode.
AFAIU, "pure"
On 25/06/2019 20:28, denisgolovan wrote:
>> You don't need any kind of new source code constructs for optimizing
>> that. The LLVM backend can already do that; in the worst case, only when
>> LTO is enabled (in case the function is declared in another unit)
>
> I am pretty sure LLVM is advanced
> You don't need any kind of new source code constructs for optimizing
> that. The LLVM backend can already do that; in the worst case, only when
> LTO is enabled (in case the function is declared in another unit)
>
> Jonas
I am pretty sure LLVM is advanced enough to make that analysis itself
On 25/06/2019 10:19, denisgolovan wrote:
>> Can I have an example of "hoisting pure functions out of loops" that you
>> speak of?
>
> Sure.
> I mean something like following (completely artificial example):
>
> function PureFunc1: ...
> function F(arg: Integer): Integer;
> var s:Integer;
> begin
At the momentI don't really have anything, but I will upload something
soon. I've only really been experimenting so far, but first I figure
I'll need to get the node tree generated if "pure" is specified as well
as "inline".
Gareth aka. Kit
On 25/06/2019 18:55, Ryan Joseph wrote:
On Jun
> On Jun 25, 2019, at 1:40 PM, J. Gareth Moreton
> wrote:
>
> This is my repository. Only one private test project so far that a friend
> and I are using to learn Test Driven Development and other languages.
>
> https://github.com/CuriousKit
>
> Currently I only use git locally, bit given
This is my repository. Only one private test project so far that a
friend and I are using to learn Test Driven Development and other languages.
https://github.com/CuriousKit
Currently I only use git locally, bit given how big this task will be
and also how iterative it will be, I will likely
On Tue, Jun 25, 2019 at 11:58 AM J. Gareth Moreton <
gar...@moreton-family.com> wrote:
> While pure and inline do have a lot of overlap and, internally, probably
> share some features for convenience (like a copy of the node tree), they
> are not the same
>
Oh yeah, not arguing that at all. Again
> On Jun 25, 2019, at 11:12 AM, J. Gareth Moreton
> wrote:
>
> Admittedly I only just set one up, admittedly to make projects to show off to
> prospective employers - I haven't got anything to show yet though.
>
> Would you suggest I share patch files on there?
I always upload my commits
While pure and inline do have a lot of overlap and, internally, probably
share some features for convenience (like a copy of the node tree), they
are not the same - for example, recursive functions can be pure, but not
inline, and functions that dereference pointers can be inlined, but not
On Tue, Jun 25, 2019 at 1:20 AM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> Correct. Though considering that we're talking about *compile time* the
> compiler *could* treat consts (in {$J-} mode) as constants if pure
> functions are involved...
>
I'd be fine with the
Admittedly I only just set one up, admittedly to make projects to show
off to prospective employers - I haven't got anything to show yet though.
Would you suggest I share patch files on there?
Gareth aka. Kit
On 25/06/2019 15:58, Ryan Joseph wrote:
On Jun 25, 2019, at 4:11 AM, J. Gareth
> On Jun 25, 2019, at 4:11 AM, J. Gareth Moreton
> wrote:
>
> Given how big this undertaking is, I will be writing a design specification
> as I go so my changes are a little more apparent and so you guys can rip it
> to shreds if I make a mistake.
Do you have a public GitHub you publish
> Long story short, it took me a brief moment to see how the optimisation
> would work until I thought about it a bit more, but if PureFunc is
> indeed pure, then that could certainly be a development goal.
Yes, you've got the idea.
The complete system has a lot of issues and edge cases.
Initially, F probably wouldn't be optimised because 'arg' is not
constant. However, if F were marked as inline (not pure) and its actual
parameter is a constant (say, 5, for the sake of argument), then there
is definitely potential for optimisation, since it would be expanded to
the
> Can I have an example of "hoisting pure functions out of loops" that you
> speak of?
Sure.
I mean something like following (completely artificial example):
function PureFunc1: ...
function F(arg: Integer): Integer;
var s:Integer;
begin
s:=0;
for i:=0 to 100 do
s:=s+PureFunc(arg);
Honestly, I consider optimisation to be my speciality, especially given
a lot of my contributions to FPC were peephole optimisations.
I did think about optimisations such as "for X := 0 to
SomeFunction(Para) do", where SomeFunction is a pure function, but then
I was told that the upper limit
Hi Gareth
I'd like to know if the scope of your interest in "pure" is just initialization
of constants or you plan to implement some optimizations as well?
I mean something like hoisting pure functions out loops.
--
Regards,
Denis Golovan
___
. we happy with the directive being '*pure*'?
On 25/06/2019 06:20, Sven Barth via fpc-devel wrote:
Am 25.06.2019 um 06:20 schrieb Marģers . via fpc-devel:
----- Reply to message -
Subject: Re: [fpc-devel] XML node dump feature
Date: otrd., 25 jūn., 03:16
From: Ben Grasset
To: FPC dev
lex examples down the line. This is
something I really want to get working!
Gareth aka. Kit
P.S. Just to clarify... we happy with the directive being '*pure*'?
On 25/06/2019 06:20, Sven Barth via fpc-devel wrote:
Am 25.06.2019 um 06:20 schrieb Marģers . via fpc-devel:
- Reply to message -----
Subject
Am 25.06.2019 um 06:20 schrieb Marģers . via fpc-devel:
- Reply to message -
Subject: Re: [fpc-devel] XML node dump feature
Date: otrd., 25 jūn., 03:16
From: Ben Grasset
To: FPC developers' list
const
A: TVec3F = (X: 1.2; Y: 2.4; Z: 3.8);
B: TVec3F = (X: 2.1; Y: 4.2; Z
- Reply to message -
Subject: Re: [fpc-devel] XML node dump feature
Date: otrd., 25 jūn., 03:16
From: Ben Grasset
To: FPC developers' list
> const
> A: TVec3F = (X: 1.2; Y: 2.4; Z: 3.8);
> B: TVec3F = (X: 2.1; Y: 4.2; Z: 8.3);
> // You can't do the next pa
On Mon, Jun 24, 2019 at 4:11 PM J. Gareth Moreton
wrote:
> "constexpr" is essentially to C++ as "pure" would be to FPC. Some of the
> methods that involve pointers and var parameters (which is probably the
> closest equivalent to the "&" parameters in C++) may be flagged as impure
> because
"constexpr" is essentially to C++ as "pure" would be to FPC. Some of the
methods that involve pointers and var parameters (which is probably the
closest equivalent to the "&" parameters in C++) may be flagged as
impure because they can't be dereferenced at compile time.
Nevertheless, a function
On Sat, Jun 22, 2019 at 4:36 PM J. Gareth Moreton
wrote:
> I've noticed you're particularly keen on pure functions... what's the
> main use that you envision for them?
>
I'm not the same person of course, but I'm pretty excited about them in
regards to the initialization of constants.
E.G. I'd
Hah, indeed I can, and I will!
I've noticed you're particularly keen on pure functions... what's the
main use that you envision for them?
Gareth
On 22/06/2019 21:32, Ryan Joseph wrote:
On Jun 22, 2019, at 3:56 PM, J. Gareth Moreton
wrote:
Thanks to Pierre's sponsorship and advice, the
> On Jun 22, 2019, at 3:56 PM, J. Gareth Moreton
> wrote:
>
> Thanks to Pierre's sponsorship and advice, the Free Pascal Compiler now
> contains the feature that allows you to dump the intermediate nodes generated
> by the compiler. When enabled with "-dDEBUG_NODE_XML" in the compiler's
>
Hi everyone,
Thanks to Pierre's sponsorship and advice, the Free Pascal Compiler now
contains the feature that allows you to dump the intermediate nodes
generated by the compiler. When enabled with "-dDEBUG_NODE_XML" in the
compiler's source code, all units will have a "NAME-node-dump.xml"
You're welcome. We just have to hope it's quality is acceptable for
Florian to merge it into the trunk!
Gareth aka. Kit
On Thu 07/02/19 05:36 , "Christo Crause" christo.cra...@gmail.com sent:
On Thu, 7 Feb 2019, 03:16 J. Gareth Moreton ___
On Thu, 7 Feb 2019, 03:16 J. Gareth Moreton I hope it proves useful. It's at least giving me some insight into how
> some things are set up.
>
> Gareth aka. Kit
>
This sounds useful, especially for someone like me who isn't that familiar
with the compiler but poke around in the compiler
I made a few extra bug fixes and tweaks over at #35017:
- When displaying the value of string constants, it will change characters
like < into < etc. You can't trick it by putting
"http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
Hi everyone,
As has been discussed a little bit on here in the past, I've done a bit
more work on my XML node dumping feature. If the compiler is built with
the "DEBUG_NODE_DUMP" define, all source files compiled with it will have
their intermediate nodes dumped to an XML file (they have .ppx
40 matches
Mail list logo
