Recent

Author Topic: Unified Pascal syntax  (Read 7716 times)

Shpend

  • Full Member
  • ***
  • Posts: 167
Unified Pascal syntax
« on: December 14, 2019, 09:31:38 pm »
hello guys,

I have come across something in Pascal (FPC), when I started again using more and more OOP.

This is, I have to say, a critic point in FPC, which bases on the structure of modules, like:

functions/procedures, record, classes, units.

More detailed: I would actually love to see that Pascal enforces the developer to write code in the same way, so to speak: Lets say this:

In my head, there shouldnt even be a need for a modeswitch to advanced records, it should be implicitly possibly

Code: Pascal  [Select][+][-]
  1. TSomeData = record
  2. {here in my head, fpc should enforce the visibility section!}
  3. public/private/strict private/protected etc...
  4.   Type
  5.      T1 = ....
  6.      T2 = ....
  7.      T3 = ....
  8.   const
  9.     C1 = ..
  10.     C2 = ...
  11.   var
  12.     V1: T1;
  13.     V2: T2;
  14. end;
  15.  

//this unfortunately, is not enforced so I can also just write all that without the enforced visibilty section, so it is implicitly guest as public which I dont see it as pascalish way, since pascal wants more and clear expression of what u are trying to archieve. So if u want public, fine, then write it also so, like be forced to name the visibilty section. I dont know, I really find these types of enforcements very useful and readable.

Another thing is, as PascalDragon once suggested me to do with my generic stuff is:

Code: Pascal  [Select][+][-]
  1. type
  2.   generic TMultiSet<T> = record
  3.   public type                                                 //why the extra "public type" here
  4.     PMultiSet = ^specialize TMultiSet<T>;
  5.   public
  6.     fField: Byte;
  7.     value: PMultiSet;
  8.   end;
  9.  

This example could also kinda show, that a good structural layout enforcement is really valuable, since saying:

Code: Pascal  [Select][+][-]
  1. type
  2.   generic TMultiSet<T> = record
  3.   public
  4.     type
  5.       PMultiSet = ^specialize TMultiSet<T>;
  6.     var
  7.       fField: Byte;
  8.       value: PMultiSet;
  9.   end;
  10.  

follows the same layout-tree-enforcement everywhere or for instance I am also sadly able to just say:

Code: Pascal  [Select][+][-]
  1. generic TMultiSet<T> = record
  2.   private  //note the missing "var" section
  3.     fField: Byte;
  4.     value: PMultiSet;
  5.  end;
  6.  

These things, and I am not joking now, prevented 2 of my best friends from joining FPC and moving from C even tho they were looking for change, since C is to much of an old-burden for them, both of my friends participated largely in the Cafu Engine development and they kinda liked the overall Idea of FPC/Delphi, so both know C kinda good I wiould assume.

Would like to hear about that, if its something for you to consider or If I should consume less drugs :---D

Best regards

Shpend
« Last Edit: December 14, 2019, 09:34:15 pm by Shpend »

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: Unified Pascal syntax
« Reply #1 on: December 14, 2019, 10:51:01 pm »
its no surprise you find fpc/Pascal clear to understand, it was generally considered a language to use to teach proper structured programming  :D :D
The only true wisdom is knowing you know nothing

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Unified Pascal syntax
« Reply #2 on: December 14, 2019, 11:02:46 pm »
FPC strives to be fully backwards compatible.
So the implicit public visibility of record fields simply aligns Object Pascal with record declarations in Wirth's original Pascal, years before sections of different visibility in records were conceived.
If Object Pascal forced you to add a visibility specifier to all record declarations, all Pascal code from the 1980s and 1990s would become invalid at a stroke.
As it is now, you can make the implicit visibility explicit, if you find that helpful.
Just as some people write
Code: Pascal  [Select][+][-]
  1. TMyClass = class(TObject)
  2. ...
  3. end;
making the ancestor class explicit, rather than writing
Code: Pascal  [Select][+][-]
  1. TMyClass = class
  2. ...
  3. end;
« Last Edit: December 14, 2019, 11:08:48 pm by howardpc »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Unified Pascal syntax
« Reply #3 on: December 15, 2019, 12:22:36 am »
Personally I think too detailed information hiding is counterproductive.

The benefits are in the first order aspects, the rest is micromanaging.

If you go that way, maybe identifiers should have ACLs ?  >:D

Shpend

  • Full Member
  • ***
  • Posts: 167
Re: Unified Pascal syntax
« Reply #4 on: December 15, 2019, 03:26:46 am »
Quote
If Object Pascal forced you to add a visibility specifier to all record declarations, all Pascal code from the 1980s and 1990s would become invalid at a stroke.

first of all, i meant actuall all modular-aspects of pascal, like: Unit, Class, Record, Object everything which has the capability of encapsulation in a wider sense, so like the overall pattern I am striving personally atleast is:

Code: Pascal  [Select][+][-]
  1.  
  2. <ModuleType> =  <Modulename>
  3.   <visibility>           #1. place
  4.     [optional]
  5.       <Type>           # if types needed, always after the visibility section
  6.       .
  7.       .
  8.       .
  9.      <Constantes>    #if constants needed, always after the visibility section
  10.       .
  11.       .
  12.       .
  13.       .
  14.     <Var>              #if variables needed, always after the visibility section
  15.       .
  16.       .
  17.       .  
  18.    //actually would have been a nice "routine" keyword too, to express that here will come numerous routines (functions/procedures)
  19.    <Routines>       #if routines needed, always after the visibility section  
  20.       .
  21.       .
  22.       .
  23.  [optional]
  24.  

The same goes actually for the UNIT too, since a unit has all these things the usual modules (class,record, object) have in common it only adds the "uses" clause on top of it but only with the difference of "interface" and "implementation" which are effectively like private and public. Which I dont know really, why these 2 Accessor-keywords didnt have been introduced by wirth, but probably they came much later, like when OOP started and that was way after that time. But interesstingly enough, within an Unit file, you have to declare both interface and implementation section no matter if you only need like constants in that file , otherwords you dont need implementation at all, it still (as I like it, correctly) forces you to write those out. I and seemingly many others would have enjoyed such a brilliant consistency throughout the entirety of Pascal a lot.

Shpend

  • Full Member
  • ***
  • Posts: 167
Re: Unified Pascal syntax
« Reply #5 on: December 15, 2019, 03:29:26 am »
Personally I think too detailed information hiding is counterproductive.

The benefits are in the first order aspects, the rest is micromanaging.

If you go that way, maybe identifiers should have ACLs ?  >:D

Would you explain that a bit more detailed to a newbie in this area, im not sure I can follow  %)

Shpend

  • Full Member
  • ***
  • Posts: 167
Re: Unified Pascal syntax
« Reply #6 on: December 15, 2019, 03:53:16 am »
another thing (but dont worry, no other programming language offer this currently AFAIK) would be to remove the keywords object and let only record/class available as an OOP-keyword, BUT: here is the clu because you can then do all these things, which are currently done by (records /advanced records; object; class)

with this new model you can do all of that with only class and record because record is implictly an object, even if you only have simple types in it or only types +  some functions, its still internally without the developer seeing it, treated by the compiler as an advanced record but without the need to define a modeswitch for it and if you indeed need the full "object" power then the compiler just implicitly recognize from its definition of what it should be treated as, with all that said, consider the following:



Code: Pascal  [Select][+][-]
  1. //CASE1. If you want a short only data holder, be it simple types, or variant types or bitfields, as long as it only contains raw simple types like how it is done by records right now.
  2.  
  3.   T_Record = record
  4.     a,b,c: byte;
  5.     d: char;
  6.  
  7.     case boolean of
  8.       fieldlist1: (a1, b1, c1: byte);
  9.       fieldlist2: (a2, b2: QWord);  //etc...
  10.   end;
  11.  
  12.   var
  13.     mySimpleRec: T_Record ;
  14.   begin
  15.     mySimpleRec.a := 10;
  16.     mySimpleRec.b := 20;
  17.     mySimpleRec.c := 255; //etc...
  18.   end;
  19.  


Code: Pascal  [Select][+][-]
  1. //CASE2. If you want a short only data holder PLUS routines and or types + const, be it simple types, or variant types or bitfields, like how its done by the [I]{$modeswitch advanced records}[/I]
  2.   T_AdvancedRecord = record
  3.   public
  4.     Type
  5.       TBla = byte;
  6.       TRangeBla = 10..189;
  7.      var
  8.        a,b,c: TBla;
  9.        d: char;
  10.        blarange: TRangeBla ;
  11.     case boolean of
  12.       fieldlist1: (a1, b1, c1: byte);
  13.       fieldlist2: (a2, b2: QWord);  //etc...
  14.  
  15.     //just some crap.. xD
  16.     function Do_1: byte;
  17.     function Do_2: Char;
  18.     procedure Do_3;
  19.   end;
  20.  
  21.   var
  22.     mySimpleRec: T_AdvancedRecord ;
  23.   begin
  24.     mySimpleRec.a := 10;
  25.     mySimpleRec.b := 20;
  26.     mySimpleRec.c := 255; //etc...
  27.     mySimpleRec.blaRange := 189;
  28.     writeln(mySimpleRec.Do_1 + mySimpleRec.a);
  29.   end;
  30.  



Code: Pascal  [Select][+][-]
  1. //CASE3. If you want a fully OOP version with polymorphie, inheritcance and stuff, you could do like this, but with the exception that it will get automatically released by the stackmanager after it leaves its current scope , like how it is done by object right now.
  2.  
  3.   T_Object = record(TAnotherClass, IAnotherInterface1, IAnotherInterface2)
  4.     a: IAnotherInterface1;
  5.     d: char;  
  6.   end;
  7.  
  8.   var
  9.     mySimpleRec: T_Object;
  10.     varOfInterface1: IAnotherInterface ;
  11.   begin
  12.     mySimpleRec.a := varOfInterface1;
  13.     mySimpleRec.b := 'C';
  14.     mySimpleRec.a.DoSomeCallHere();
  15.   end;
  16.  

Yea and class is just remains a class, how it is done currently.
« Last Edit: December 15, 2019, 04:09:00 am by Shpend »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Unified Pascal syntax
« Reply #7 on: December 15, 2019, 12:10:11 pm »
Personally I think too detailed information hiding is counterproductive.

The benefits are in the first order aspects, the rest is micromanaging.

Informating hiding is hiding identifiers from others scopes (classes/units/whatever). I firmly believe in keeping that simple. (IMHO the whole "strict*" was already worse than the actual problem).  private/protected/public is good enough.

Quote
If you go that way, maybe identifiers should have ACLs ?  >:D

ACL are access control lists, lists like file permissions on windows that list who (and or which group) can access what.

simone

  • Hero Member
  • *****
  • Posts: 573
Re: Unified Pascal syntax
« Reply #8 on: December 15, 2019, 01:28:14 pm »
Personally I think too detailed information hiding is counterproductive.

The benefits are in the first order aspects, the rest is micromanaging.

Informating hiding is hiding identifiers from others scopes (classes/units/whatever). I firmly believe in keeping that simple. (IMHO the whole "strict*" was already worse than the actual problem).  private/protected/public is good enough.


I basically agree. The problem is that the object pascal language has a peculiar notion of private (and protected), since a private member of a class is visible not only within the class to which it belongs, but also outside, within the unit where the class itself is defined. This does not happen for example in C++ and Java. Hence the need for the 'strict' keyword to restrict visibility.

« Last Edit: December 15, 2019, 01:33:25 pm by simone »
Microsoft Windows 10 64 bit - Lazarus 3.0 FPC 3.2.2 x86_64-win64-win32/win64

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unified Pascal syntax
« Reply #9 on: December 15, 2019, 01:31:20 pm »
Quote
If you go that way, maybe identifiers should have ACLs ?  >:D
ACL are access control lists, lists like file permissions on windows that list who (and or which group) can access what.

Actually, I do have some sympathy with that one: perhaps an explicit export <identifier> to <unit> or similar.

However it could probably be simulated adequately by having a sensitive class issue access tokens on request, and then checking that that token was being presented (by the correct thread/unit/class) during subsequent operations.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Shpend

  • Full Member
  • ***
  • Posts: 167
Re: Unified Pascal syntax
« Reply #10 on: December 15, 2019, 02:02:42 pm »
Is anyone of you attracted to the record/class idea I mentioed above?

Like making records implicitly advanced and object-wise, like supporting everything that a class can but is still allocated on the stack.

I feel this bringing a modeswitch into fpc feels very deprecated to me atleast.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Unified Pascal syntax
« Reply #11 on: December 15, 2019, 02:10:47 pm »
Personally I think too detailed information hiding is counterproductive.

The benefits are in the first order aspects, the rest is micromanaging.

Informating hiding is hiding identifiers from others scopes (classes/units/whatever). I firmly believe in keeping that simple. (IMHO the whole "strict*" was already worse than the actual problem).  private/protected/public is good enough.


I basically agree. The problem is that the object pascal language has a peculiar notion of private (and protected), since a private member of a class is visible not only within the class to which it belongs, but also outside, within the unit where the class itself is defined. This does not happen for example in C++ and Java. Hence the need for the 'strict' keyword to restrict visibility.

That's what I meant with worse than the problem. The addition (and having six levels) is worse than the original problem (three levels with some shortcuts for use within the same unit).

Note that the exceptions are partially rooted in the unit system, a concept that  e.g. Java doesn't have, and C++ is only discussing about in committees. C++ is  30 years back  on that front, so it is logical that they don't support it.

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Unified Pascal syntax
« Reply #12 on: December 15, 2019, 02:35:47 pm »
Is anyone of you attracted to the record/class idea I mentioed above?

Like making records implicitly advanced and object-wise, like supporting everything that a class can but is still allocated on the stack.

I feel this bringing a modeswitch into fpc feels very deprecated to me atleast.
I think In Delphi mode you don't need an advancedrecords modeswitch to give you advanced records.
FPC is already halfway there with old-style objects whose declarations default to public and are allocated on the stack.
Of course they lack proper inheritance.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Unified Pascal syntax
« Reply #13 on: December 15, 2019, 03:59:41 pm »
Of course they lack proper inheritance.
Since when? KOL or FV are counter-examples. That's a load of Boris. Look how fp is build.
« Last Edit: December 15, 2019, 04:03:14 pm by Thaddy »
Specialize a type, not a var.

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Unified Pascal syntax
« Reply #14 on: December 15, 2019, 06:33:51 pm »
Sorry, confused message. 
I meant advanced records currently lack inheritance. Perhaps they always will?

 

TinyPortal © 2005-2018