Difference between revisions of "Modernised Pascal"

From Lazarus wiki
Jump to navigationJump to search
Line 89: Line 89:
  
  
 +
''Ough, there is more and more to add :)''
 +
'''10: string*integer operation.'''
 +
If Pascal having <string or char> + <string or char> operation, then why not have <string or char> * <positive integer> operation, meaning duplicationg strings ? :)
 +
 +
'''11: FOR syntax extensions''' - can't determine if i am jokling or am talking seriously.
 +
I always felt that FOR is not straight about its variables. One one hand it is not variable, but rather specfic local semi-constant: it cannot be assigned to, it becomes garbage after loop is executed|jumped out. One another hand it is semi-variable since it needs declaration of variable in outer block. And it destroys previous content of that variable. So, just like about var-parameter in procedures, it makes me think of two orthogonal extensions of FOR:
 +
for i:integer := 10 to 20 do ...; // (1)
 +
 +
for var i := 10 to 20 do ...; // (2)
 +
 +
var i: integer;
 +
begin
 +
  i := 5;
 +
  for  i: integer := i to 10 do write(i:3); //(3)
 +
  writeln (^M^J'i is still ', i);
 +
end;
 +
 +
The examples demonstrate how this specialised syntax patterns would differ from current FOR, making it choose some consistent modus operandi.
 +
(1) means that i is for-local. It does not need declaration of i outside of FOR, if it was declared, that outer i would be pushed out of scope within the loop. It is read-only and is truely undefined (non-existent) before and after the loop.
 +
(2) moves back to Turbo Pascal code generator, where for was more like C++ one. No optimisations, like running ECX register from 9 to 0 instead of incrementing from 1 to 10. Variable is to be declared in outer block (it is like passed to FOR like var-parameters to procedures). It can be changed at any time within the loop. It really works over that variable, so after loop is escaped variable is keeping last value and after loop completion it would keep to-margin+1 ot downto-margin-1 value.
 +
(3) shows the last point thatouter i is visible and may be used in localisation of local i. After local i is initialised, outer i is get out of scope, and heince its value is not destroyed by loop.
 +
 +
I feel that both (1) and (2) models are more strict and consistend that the current Delphi for model.
 
----
 
----
  

Revision as of 13:49, 26 January 2006

more strongly syntax

1)

if ... then

 ...

elsif {!}

 ...

else

 ...

end; {!}

2)

if 1 > a < 3 then ... {!} end

3)

 for i := 1 to 30 {+} step 5 {+.} do
 end {!}

Remark: "step" keyword seems to be cloned from Basic. If this to be implemented, then it is better to be replaced with "by" from Component Pascal.

4)

 while ... do ...
 end; {!}

5) alias for long name:

 when a = other_long_name1, b = other_long_name2 {!} do
   a.method1;
 end; {!}

6) block variables & initialization in declaration section:

  declare // ?
    var
      a: integer := DataSet1.Field[1].AsInteger;
    const
      b: integer = 1;
  begin
    ...
  end;

7) (?) property information 'access' abstraction ( on code compilation phase ):

  TClass1 = class
  ...
  published
    property FieldInt: Integer read fFieldInt write fFieldInt default 100;
  end;
  constructor TClass1.Create(...   
  begin
    inherited;
    fFieldInt := TClass1.FieldInt.DefaultValue; {!} // for non object types
  end;
  procedure TClass1.Check(...
  begin
    if fFieldInt = TClass1.FieldInt.DefaultValue then
       ...
    end

8) unified as and is, as made in Component Pascal (aka Oberon/F, last Wirth's language):

   //   usual code is like that
   if MyVar is MyClass then
      with MyVar as MyClass do begin
         ...
      end else begin
         ...
      end;

(* obvious, that as operator is not required here from practical point of view. Since both as and is operators seems to be procedures running over class'es RTTI, it is hard for compiler to remove call to as. It also places a rooks at the doorstep of programmer, since he might, when later renaming classes or variables, rename only one from the pair. In Component Pascal it was decided that IS operator, if met inside execution flow control statements (if, case, while) and evaluated to true, assures the corresponded execution path that MyVar really belongs to MyClass, in other words, acting like implicit AS but without extra work through classes inheritance tree. So the code, beeing simplified, looks like that: *)

   if MyVar is MyClass then begin
         ... //here MyVar is MyClass, compiler knows that
      end else begin
         ... //here MyVar is not MyClass, compiler knows that
      end;
 

That is not to break any compatibility with existing code or coding habits. As well, this seems to be relatively simple change.

9) merging of interface/implementation, like in Component Pascal: Borland's idea of interface/implementations perhaps was borned analyzing C's .h files. It seems pretty and rigorous, but has its disadvantages. Some persons hates when changing prototype of overloaded function in interface they need to search for it in implementation. Other raises question of encapsulation leaks. They argue that there easily can be a situation, when unit publishes Class A, in unit's interface section. Next, unit has some private Class B, which is not to be published. Next, Class И is the type on private member variable within Class A. With current syntax rules that enforces the programmer to move Class И to interfae section, thus publishing it, while he did not wanted too. In Component Pascal instead the visibility of procedure,etc is determined by presence of asterisk in it's declaration. Something like that: "Procedure* PublishedFunction(vars);" and the like for classes, vars, etc. That is a big change, i guess, it would require special switch, like Mac Mode, or automagical detection if it was interface met first, or declaration with asterisk. It also looks less rigorous than habit-blessed interface/implementation pair. However it seems that might be more rigouruos in terms of encapsulating indeed.


Ough, there is more and more to add :) 10: string*integer operation. If Pascal having <string or char> + <string or char> operation, then why not have <string or char> * <positive integer> operation, meaning duplicationg strings ? :)

11: FOR syntax extensions - can't determine if i am jokling or am talking seriously. I always felt that FOR is not straight about its variables. One one hand it is not variable, but rather specfic local semi-constant: it cannot be assigned to, it becomes garbage after loop is executed|jumped out. One another hand it is semi-variable since it needs declaration of variable in outer block. And it destroys previous content of that variable. So, just like about var-parameter in procedures, it makes me think of two orthogonal extensions of FOR:

for i:integer := 10 to 20 do ...; // (1)

for var i := 10 to 20 do ...; // (2)
var i: integer;
begin 
  i := 5;
  for  i: integer := i to 10 do write(i:3); //(3)
  writeln (^M^J'i is still ', i);
end;

The examples demonstrate how this specialised syntax patterns would differ from current FOR, making it choose some consistent modus operandi. (1) means that i is for-local. It does not need declaration of i outside of FOR, if it was declared, that outer i would be pushed out of scope within the loop. It is read-only and is truely undefined (non-existent) before and after the loop. (2) moves back to Turbo Pascal code generator, where for was more like C++ one. No optimisations, like running ECX register from 9 to 0 instead of incrementing from 1 to 10. Variable is to be declared in outer block (it is like passed to FOR like var-parameters to procedures). It can be changed at any time within the loop. It really works over that variable, so after loop is escaped variable is keeping last value and after loop completion it would keep to-margin+1 ot downto-margin-1 value. (3) shows the last point thatouter i is visible and may be used in localisation of local i. After local i is initialised, outer i is get out of scope, and heince its value is not destroyed by loop.

I feel that both (1) and (2) models are more strict and consistend that the current Delphi for model.



  1. Rejected. A proposal like this show exactly why begin/end is elegant, you don't need elseif.
  2. Rejected. Only purpose is to save some typing.
  3. "step" proposal not rejected (but not accepted as well), removal of "begin" rejected
  4. Rejected ... for removal of "begin"
  5. Rejected; aliases makes code harder to read.
  6. Don't understand what you want here.
  7. const field_default=100 does the same. Rejected.

Daniel-fpc 11:02, 17 Dec 2005 (CET)