[fpc-devel] Debug compiler
lazarus at kluug.net
Sun Nov 1 06:26:47 CET 2015
On 01.11.2015 00:11, Jonas Maebe wrote:
> On 31/10/15 21:28, Ondrej Pokorny wrote:
>> The argument that the tenumeratornode concept is completely different
>> from other nodes is correct - but if you think about the syntax you will
>> see that also the syntax is completely different from other pascal
>> syntax so you need such a unique node.
> That is a very good argument not to add it...
Yes, my argument that the "syntax is completely different from other
pascal syntax" is misleading. I put it wrong. It is not different - its
a new extension within the current pascal syntax:
E.g. the code
* for s in Self.StringArray do**
* would compile even now if *StringArray* was an "array of xyz" or a
class/record/interface with GetEnumerator function. The syntax is
already present in Pascal. I only want to extend it for array properties
(this extension is new and unique).
The fact that the syntax is unique ensures that no legacy code can be
broken. I personally don't think that adding many new compiler features
is necessary, but this one really is useful - with this syntax you could
easily and systematically add enumerators to a lot of different
properties in the RTL/LCL you cannot use in a for-in loop now:
- etc, etc
Michael liked it as well:
+ I was wrong about the need to use "tenumeratornode". Actually you can
use "tcallnode" and get *pd* and *expr* for
*create_enumerator_for_in_loop* from its properties in function
(you have to find the compatible overload)
(If you don't know what I mean I can send you the code. It's working
like a charm.)
The only thing we need is a new flag/whatever so that
*create_for_in_loop* knows that "tcallnode(expr)" contains an enumerator
function. tnode.flags seems to be full :( Do you have any suggestions?
If we sort this out, 2 more arguments against it are nil :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel