On Thu, Jul 16, 2015 at 1:39 PM, Sven Barth <pascaldra...@googlemail.com> wrote:
> On 16.07.2015 18:02, Marcos Douglas wrote:
>>
>> [...]
>>
>> Yes, but do you think this is more verbose unnecessarily? Because the
>> syntax TFoo<T> (I mean this "<>") show us that is a generic, don't?
>
>
> This might be the case for a human, but for a compiler/parser that is a
> completely different topic. Take the following example code (with generic
> methods to highlight the problems I'm facing right now):
>
> === code begin ===
>
> type
> TTest = class
> function Add: LongInt;
> function Add<T>(aLeft, aRight: T): T;
> end;
>
> var
> t: TTest;
> i: LongInt;
> begin
> i := t.Add<LongInt>(2, 4);
> end;
>
> === code end ===
>
> The parser sees the following tokens after the assignment: identifier ('t'),
> point, identifier ('Add'), less than, identifier ('LongInt'), greater than,
> left parenthesis, etc.
> Our parser only knows the next token, up until the "greater than" (or if
> there is more than one type parameter the "," for the next parameter) the
> parser does not know whether it is dealing with a call to generic method
> Add<X, Y, Z> or a call to a function Add followed by a comparison. This is
> highly ambigous and a real PITA to implement.
>
> In non-Delphi modes this is much more straight forward:
>
> === code begin ===
>
> type
> TTest = class
> function Add: LongInt;
> generic function Add<T>(aLeft, aRight: T): T;
> end;
>
> var
> t: TTest;
> i: LongInt;
> begin
> i := t.specialize Add<LongInt>(2, 4);
> end;
>
>
> === code end ===
>
> No sambiguity here. Nice :)
I see... More verbose is more easy to compile, making a parser without
ambiguity and faster.
Regards,
Marcos Douglas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
