<HTML>
<div><style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>Thanks Sven,</div><div><br>
</div><div>Sorry if I'm bringing up obvious points. I've set "pure" to be interface-only - it's a little tricky because if you now specify it in the main source file, it says that it can't be used in the implementation section, even though, really, the main file doesn't have such section. Still, that can be dealt with.</div><div><br>
</div><div>This will require a lot of testing once I start submitting patches!<br>
</div><div><br>
</div><div>Gareth aka. Kit<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Fri 10/08/18 06:45 , "Sven Barth" pascaldragon@googlemail.com sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">Gareth sent me the following two mails in private, but they were ment
<br>
for the list:
<br>
<br>
Am 09.08.2018 um 16:18 schrieb J. Gareth Moreton:
<br>
<span style="color: rgb(102, 102, 102);">> Thanks Sven. Normally I would agree with
</span><br>
<span style="color: rgb(102, 102, 102);">> "pure" only belonging in the interface
</span><br>
<span style="color: rgb(102, 102, 102);">> section, but it causes problems when you
</span><br>
<span style="color: rgb(102, 102, 102);">> try to put a pure function inside the main
</span><br>
<span style="color: rgb(102, 102, 102);">> program block, as the entire thing is
</span><br>
<span style="color: rgb(102, 102, 102);">> considered equivalent to implementation.
</span><br>
<span style="color: rgb(102, 102, 102);">> Also, inline is allowed in the
</span><br>
<span style="color: rgb(102, 102, 102);">> implementation section, and the two follow
</span><br>
<span style="color: rgb(102, 102, 102);">> similar rules in regards to their calls
</span><br>
<span style="color: rgb(102, 102, 102);">> being modified.
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> Just to clarify, "pure" doesn't change
</span><br>
<span style="color: rgb(102, 102, 102);">> anything in regards to the parameter types
</span><br>
<span style="color: rgb(102, 102, 102);">> or how a call with variable arguments is
</span><br>
<span style="color: rgb(102, 102, 102);">> handled. The raw signature shouldn't
</span><br>
<span style="color: rgb(102, 102, 102);">> change. It's an optimisation hint. At
</span><br>
<span style="color: rgb(102, 102, 102);">> least it is in a perfect world!
</span><br>
<br>
Am 09.08.2018 um 23:10 schrieb J. Gareth Moreton:
<br>
<span style="color: rgb(102, 102, 102);">> I asked the question because I stumbled across something interesting.
</span><br>
<span style="color: rgb(102, 102, 102);">> I've been using the following set of functions to see how the compiler
</span><br>
<span style="color: rgb(102, 102, 102);">> handles things that are a bit out of order (using 'inline' as a
</span><br>
<span style="color: rgb(102, 102, 102);">> temporary stand-in):
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> program PureTest;
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> function PureMax(const a: Double; const b: Double): Double; forward;
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> procedure TestFunc;
</span><br>
<span style="color: rgb(102, 102, 102);">> begin
</span><br>
<span style="color: rgb(102, 102, 102);">> WriteLn(PureMax(2.0, 3.0));
</span><br>
<span style="color: rgb(102, 102, 102);">> end;
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> function PureMax(const a: Double; const b: Double): Double; inline;
</span><br>
<span style="color: rgb(102, 102, 102);">> begin
</span><br>
<span style="color: rgb(102, 102, 102);">> if (a > b) then
</span><br>
<span style="color: rgb(102, 102, 102);">> Result := a
</span><br>
<span style="color: rgb(102, 102, 102);">> else
</span><br>
<span style="color: rgb(102, 102, 102);">> Result := b;
</span><br>
<span style="color: rgb(102, 102, 102);">> end;
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> begin
</span><br>
<span style="color: rgb(102, 102, 102);">> TestFunc;
</span><br>
<span style="color: rgb(102, 102, 102);">> end.
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> ****
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> Turns out, to my surprise, after analysing the nodes and the
</span><br>
<span style="color: rgb(102, 102, 102);">> disassembly, that "PureMax" is not inlined inside the TestFunc
</span><br>
<span style="color: rgb(102, 102, 102);">> routine. I haven't tested units yet, but would a similar situation
</span><br>
<span style="color: rgb(102, 102, 102);">> occur if a function is not defined as inline in the "interface"
</span><br>
<span style="color: rgb(102, 102, 102);">> section and only the "implementation" section (unless the caller
</span><br>
<span style="color: rgb(102, 102, 102);">> appears after said function in the source file)?
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> Either way, I'm leaning towards making the new "pure" directive an
</span><br>
<span style="color: rgb(102, 102, 102);">> interface-only directive as Sven suggested, as that will make things a
</span><br>
<span style="color: rgb(102, 102, 102);">> lot easier if a pure function is used as part of a constant
</span><br>
<span style="color: rgb(102, 102, 102);">> definition. After all, "pure" would have a bit more of a notable
</span><br>
<span style="color: rgb(102, 102, 102);">> effect than "inline" because it dictates where the function can and
</span><br>
<span style="color: rgb(102, 102, 102);">> cannot be used.
</span><br>
<br>
I hadn't thought that I need to explain that, but apparantly you haven't
<br>
yet reached that far in your research of the compiler, so:
<br>
- of course I only mean that it's an interface-only modifier if there
<br>
*is* an interface section; routines that are - inside a unit - only
<br>
declared inside the implementation section are obviously exempt from
<br>
this (thus also for the program file)
<br>
- again I wrote that I don't mean that "pure" modifies the parameters,
<br>
but it modifies the meta data (most importantly checksum) of the
<br>
interface section when you add a modifier flag inside the implementation
<br>
section. The compiler first handles the interface sections of units and
<br>
might then compile interface sections or even implementation sections of
<br>
other units depending on the dependencies between the units. If a flag
<br>
only appears in the implementation section than this messes up this
<br>
whole thing as the other units would need to be recompiled. This is
<br>
already a mess with "inline" so we don't need to do that with "pure" as
<br>
well, especially as we don't need to be Delphi compatible here.
<br>
- yes, it is correct that the compiler's capability to inline depends on
<br>
the order of the routine definitions. The compiler generates the code
<br>
routine by routine so if the routine's body has not yet been encountered
<br>
then it can't be inlined. (When using generic specializations it
<br>
triggeres the generation of the specialized routine bodies before
<br>
generating the routine to avoid "inline" not working for generics) For
<br>
"pure" we can even go so far as to say that a routine body *must* be
<br>
available to be able to call it inside another "pure" routine.
<br>
Everything else would be an error.
<br>
<br>
I hope this clears things up a bit.
<br>
<br>
Regards,
<br>
Sven
<br>
<br>
<br>
</blockquote></HTML>