[fpc-pascal] Interface syntax: Is possible don't use specialize in mode objfpc?

silvioprog silvioprog at gmail.com
Fri Jul 17 05:02:25 CEST 2015


On Thu, Jul 16, 2015 at 5:40 PM, Sven Barth <pascaldragon at googlemail.com>
wrote:

> On 16.07.2015 22:17, Maciej Izak wrote:
>
>> 2015-07-16 17:23 GMT+02:00 Sven Barth <pascaldragon at googlemail.com
>> <mailto:pascaldragon at googlemail.com>>:
>>
>>
>>     Then let me tell you that generic methods will arrive in mode ObjFPC
>>     (and thus its syntax) first, because the Delphi syntax is a PITA to
>>     parse/handle.
>>
>>     (in fact generic methods are already working in mode ObjFPC in my
>>     local repo, I just want to get the Delphi ones working a little bit
>>     before commiting to trunk)
>>
>>
>> @Sven, @Michael
>>
>> I am using generics all the time for many things.
>>
>> IMO using "generic/specialize" syntax because it is more simple to
>> implement in compiler is very strange motivation. Using specialize
>> keyword maybe is good in pure theory but is non practical (generic
>> keyword in type declaration is not so bad).
>>
>> You can torture me (!!!) but I will not use so many unnecessary words
>> for simple things.
>> By using this complicated syntax you will kill all functional/generic
>> approach.
>>
>> Advice "if you like shorter syntax then go to other language" is no
>> solution for me. I like some modern versions of Pascal like presented in
>> Oxygen and till Delphi XE2 (! many things after XE2 is pure evil).
>>
>> I am working on smart pointers/objects (some evolution/for the purposes
>> of Generics.Collections). Syntax with generic/specialize is not "smart"
>> for my branch:
>>
>> =============== CODE BEGIN ===============
>> {$MODE SPARTA}
>> var
>>    X: strong TDictionary<weak TList<Integer>, string>;
>>
>
> Prefixed modifiers are the /worst/ you can do for Pascal.
>
>  { sugar syntax for
>> var
>>    X: SmartObj<TDictionary<WeakObj<TList<Integer>>, string>>;  }
>> ===============  CODE END  ===============
>> so probably in ObjFPC, code above will become:
>> =============== CODE BEGIN ===============
>> {$MODE OBJFPC}
>> type
>>    TList_Integer = specialize TList<Integer>;
>>    WeakObj_TList_Integer = specialize WeakObj<TList_Integer>;
>>    TDictionary_WeakObj_TList_Integer_String = specialize
>> TDictionary<WeakObj_TList_Integer, string>;
>>    SmartObj_TDictionary_WeakObj_TList_Integer_String = specialize
>> SmartObj<TDictionary_WeakObj_TList_Integer_String>;
>> var
>>    X: SmartObj_TDictionary_WeakObj_TList_Integer_String;
>> ===============  CODE END  ===============
>>
>> Another simple example. Maybe not a good example to follow, but it shows
>> the problems:
>>
>
> The generic and specialize keywords and inline specialization are two
> completely different topics (plus nested specializations, which are simply
> not supported yet). While currently mode FPC uses the keywords, but does
> not allow inline specializations I'm in favor of allowing the latter in
> mode ObjFPC as well, because with the future addition of generic methods it
> would simply be strange to not allow it. Also we already allow it for
> parameters and partially for variable declarations as well, so not allowing
> it in code is simply inconsistent...
>
> In the end your code above will look like this in mode ObjFPC:
>
> === code begin ===
>
> var
>   X: specialize SmartObj<specialize TDictionary<specialize
> WeakObj<specialize TList<Integer> >, string> >;
> // the spaces between the "> >" are added, because I don't know yet
> whether I'll be able to deal with the fact that the scanner always converts
> ">>" to "shr" (and "<<" to "shl")
>
> === code end ===
>
> Regards,
> Sven


Hm... and more, the 'i := 1 << 1' isn't a "more Pascal-like" syntax, IMHO.
=)

It compiles in '$mode delphi', but the BCC doesn't allows this sintax,
returning an "Expression expected but '<' found". What do you think about
doing it (... Integer>>) possible in $mode delphi? =)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20150717/2e75a8c5/attachment.html>


More information about the fpc-pascal mailing list