Recent

Author Topic: Evaluation of constant statements  (Read 7480 times)

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: Evaluation of constant statements
« Reply #90 on: September 25, 2022, 01:54:34 am »
They can still share the data type if you declare them separately:

Code: Pascal  [Select][+][-]
  1. var
  2.   c: array [0..3] of byte absolute a;
  3.   d: array [0..3] of byte absolute b;
  4.  

That works because equal arrays are considered assignment compatible.

Hmmm....

https://lazarus-ccr.sourceforge.io/fpcdoc/user/userse63.html

Quote
Error: Incompatible types: got ”arg1” expected ”arg2”
There is no conversion possible between the two types. Another possiblity is that they are declared in different declarations:
Code: Pascal  [Select][+][-]
  1.  Var  
  2.     A1 : Array[1..10] Of Integer;  
  3.     A2 : Array[1..10] Of Integer;  
  4.  
  5.  Begin  
  6.     A1:=A2; { This statement also gives this error. It  
  7.               is due to the strict type checking of Pascal }  
  8.  End.
 

Hmmmmmmm.....

Thaddy

  • Hero Member
  • *****
  • Posts: 14210
  • Probably until I exterminate Putin.
Re: Evaluation of constant statements
« Reply #91 on: September 25, 2022, 09:05:29 am »
Note the bizarre declaration  (1..)  :P
Specialize a type, not a var.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Evaluation of constant statements
« Reply #92 on: September 25, 2022, 09:52:30 pm »
Code: Pascal  [Select][+][-]
  1. program talternatives;
  2. var
  3.   t: array(.0..20.) of LongInt;
  4. begin
  5.   t(.0.) := 21;
  6.   t(.10] := 42;
  7.   t[5.) := 4;
  8. end.
Berck ... it compiles and run (no Jedi CF for that program) but where is the explanation for this strange syntax of indices.

They are called digraphs and some programming languages have them. Even Delphi supports that. ;)

[(though (* and *) only work mixed with { and } in ISO mode)

if by "mixed" you meant" nested", then sounds like a bug, because Delphi handles them.
Not sure about TP, i believe it did but might remember wrong.

Or, if you meant that *) closes the { - then "deisgn by committee" at it's finest

FPC supports nesting comments as well. I really mean closing one with the other and that is considered to work in ISO Pascal, because the tokens are handled separately (that's why [5.) works as well for example).

Ideally we would need three stacks not two - but in the 286 tight set of registers it would be really problematic. AMD64 then, while increasing number and orthogonalizing use for general registers, lacks FS/GS.

386 would lend us FS or GS for data-stack, since we would have to use some register for pointer. BP? is SS-stack would only have control flow information (and saved registers), then no one would, in normal code, use SS:[BP+const]. So we could re-assign BP to be FS:[BP+const] base for local variables abd variable parameters. The binary code would be really bloated then with SEGFS prefixes, yet for the sake of security...

FS and GS themselves are still supported on AMD64, cause Microsoft required that from AMD, because they use FS on i386 Windows for the Thread Environment Block and for AMD64 Windows they use GS for that. ;)

They can still share the data type if you declare them separately:

Code: Pascal  [Select][+][-]
  1. var
  2.   c: array [0..3] of byte absolute a;
  3.   d: array [0..3] of byte absolute b;
  4.  

That works because equal arrays are considered assignment compatible.

Hmmm....

https://lazarus-ccr.sourceforge.io/fpcdoc/user/userse63.html

Quote
Error: Incompatible types: got ”arg1” expected ”arg2”
There is no conversion possible between the two types. Another possiblity is that they are declared in different declarations:
Code: Pascal  [Select][+][-]
  1.  Var  
  2.     A1 : Array[1..10] Of Integer;  
  3.     A2 : Array[1..10] Of Integer;  
  4.  
  5.  Begin  
  6.     A1:=A2; { This statement also gives this error. It  
  7.               is due to the strict type checking of Pascal }  
  8.  End.
 

Hmmmmmmm.....

The documentation should probably be updated then, cause that's only true in specific modes (definitely TP and Delphi, maybe also the ISO and ExtPas ones).

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: Evaluation of constant statements
« Reply #93 on: September 26, 2022, 12:26:34 am »
FS and GS themselves are still supported on AMD64, cause Microsoft required that from AMD, because they use FS on i386 Windows for the Thread Environment Block and for AMD64 Windows they use GS for that. ;)

Then it probably was reverse. I remember that AMD64 deprecated selector registers, and that FS/GS were a special case. Perhaps i remembered the opposite of what happenned.

Quote from: AMD
4.3.3 Segmentation in 64-Bit Mode

In 64-bit mode, segmentation is disabled. The segment-base value is ignored and treated as 0 by the
segmentation hardware. Likewise, segment limits and most attributes are ignored. There are a few
exceptions.

....

DS, ES, and SS Registers in 64-Bit Mode. In 64-bit mode, the contents of the ES, DS, and SS
segment registers are ignored. All fields (base, limit, and attribute) in the hidden portion of the
segment registers are ignored.



Quote
That works because equal arrays are considered assignment compatible.

...

The documentation should probably be updated then, cause [the opposite] true in specific modes (definitely TP and Delphi, maybe also the ISO and ExtPas ones).

Is there some pragma to relax it in TP/Delphi modes too?

Because, frankly, this restriction lost any standing after Delphi got generics.  TP/Delphi type system was always not very consistent, but that took one extra.

Official declaraiont is type TArray<X> = array of X;
Yet assignment compatibility rules are different. 
TStringDynArray in RTL (at least up to XE2) was not redefined as generic array, yet new IOUTils unit, AFAIR, returns new TArray<string> instead of old TStringDynArray, making it not compatible with other parts of RTL. A mess...

And also type T = type string; is ignored. Whoever invented "assignment compatibility" and implemented it so inconsistently deserves some free heat deep down there...

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Evaluation of constant statements
« Reply #94 on: September 26, 2022, 01:43:17 pm »
Is there some pragma to relax it in TP/Delphi modes too?

No, there's not. Also FPC does not have “pragmas” they are called “directives”.

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: Evaluation of constant statements
« Reply #95 on: September 26, 2022, 02:40:01 pm »
Is there some pragma to relax it in TP/Delphi modes too?

No, there's not. Also FPC does not have “pragmas” they are called “directives”.

That's a miss.
OTOH, should such rigorous a check be kept even in TP/Delphi mode today?

From language consistency point, it is harmful now, that generic types are in both Delphi and FPC. It makes the same in essence entities have different behavior.
From compatibiltiy point - let FPC "import" code from TP/Delphi and compile it immediately with no (or at least minimum) adaptations  - it adds nothing.
It also, like nay other special case, adds to compiler complexity and mantainance burden.

Frankly, i believe this level of purity is obsolted long ago. It made sense for 1970-s J&W Pascal (only had static arrays, which immediately proved a problem for procedure calls already in USCD) and the purposes of it: no practical programming, education only, force good habits into students, and cutting corners they would learn on their own. But when application programming became largely selecting and combinating ready libraries - it only became a source of inconsistencies in Delphi.  TStringDynArray vs TBytes vs many ad hoc types, etc. Implementing this restriction feels today like showing off "look, how closely we can emulate TP/D"

-----------------

"directive" is rather ambiguous a word. "stdcall" or "virtual" after procedure declaration are directives too, and many more examples.  A specially formatted comment that changes compiler behavior though is a rather specific sense, immediately evident to anyone reading the "pragma" term, which is much shorter than "compiler directive" of J&W.

---------------

Now, coming back to writeable constants...

D:\fpcupdeluxe\lazarus\lcl\widgetset\wsstdctrls.pp

Code: Pascal  [Select][+][-]
  1. procedure RegisterToggleBox;
  2. const
  3.   Done: Boolean = False;
  4. begin
  5.   if Done then exit;
  6.   WSRegisterToggleBox;
  7. //  if not WSRegisterToggleBox then
  8. //    RegisterWSComponent(TToggleBox, TWSToggleBox);
  9.   Done := True;
  10. end;
  11.  

If to pursue structural programming ideals, those should be re-written to class vars or to unit's local global vars, but unless someone does it - LCL design is dependent upon having $J+ mode. I think no one would bother to fix it though. And LCL remain laden with this horrorific concept forever, despite all the forum anger :-)

BrunoK

  • Sr. Member
  • ****
  • Posts: 452
  • Retired programmer
Re: Evaluation of constant statements
« Reply #96 on: September 26, 2022, 07:13:51 pm »
Code: Pascal  [Select][+][-]
  1. procedure RegisterToggleBox;
  2. const
  3.   Done: Boolean = False;
  4. begin
  5.   if Done then exit;
  6.   WSRegisterToggleBox;
  7. //  if not WSRegisterToggleBox then
  8. //    RegisterWSComponent(TToggleBox, TWSToggleBox);
  9.   Done := True;
  10. end;
  11.  

If to pursue structural programming ideals, those should be re-written to class vars or to unit's local global vars, but unless someone does it - LCL design is dependent upon having $J+ mode. I think no one would bother to fix it though. And LCL remain laden with this horrorific concept forever, despite all the forum anger :-)

In the context where it is used, that const done (may be sometimes registered) is just perfect.

You obviously don't know anything of the context where this specific const is used and have absolutely no idea how to do it in a better way.

You might take time to pause your rubbish auto-generator and show what working code you might be able to produce.

Also, there is a option to do spellchecking that you might take time to learn instead of producing random doctoral messages.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Evaluation of constant statements
« Reply #97 on: September 26, 2022, 07:46:14 pm »
In the context where it is used, that const done (may be sometimes registered) is just perfect.

Subject to the poor choice of "const" as opposed to e.g. "static", I'm inclined to agree. I think that we can, in general, also agree that the code produced by that example would be trivial.

I am troubled, however, by the likelihood that some computer science type (and I am not thinking about any particular person when I say that) would insist that it be more appropriately described by a lambda or a function reference or a generic singleton or... hopefully you get my drift.

ALGOL and Pascal both started off as simple languages and were demonstrably capable of good work. Much of their subsequent bloat is, in my opinion, unnecessary and regrettable.

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

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: Evaluation of constant statements
« Reply #98 on: September 26, 2022, 07:48:17 pm »
re-written to class vars or to unit's local global vars
You ... have absolutely no idea how to do it in a better way.

Man, before you answer - try reading first.
When you answer without reading, it is fast, but funny.

Subject to the poor choice of "const" as opposed to e.g. "static", I'm inclined to agree.

Mmm...  How then can i check in debugger or in my own code, if registration happenned or not?
It is not big a problem, but it shows this code is not ideal too.
Even if static was used.
« Last Edit: September 26, 2022, 07:51:21 pm by Arioch »

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: Evaluation of constant statements
« Reply #99 on: September 26, 2022, 08:20:37 pm »
Such a burning pride instead of casual "no big deal"...

After that I really started looking deep, maybe i am missing some non-trivial use of seemingly trivial flags? 

And funny thing, is this "done" doing nothing but wasting memory? Not a lot, just a single byte, but still.
Unless i missed some esoteric places where RegisterWinControl could've been called from, there seems to only be one single caller.

D:\fpcupdeluxe\lazarus\lcl\include\wincontrol.inc

Code: Pascal  [Select][+][-]
  1. class procedure TWinControl.WSRegisterClass;
  2. const
  3.   Registered : boolean = False;
  4. begin
  5.   if Registered then
  6.     Exit;
  7.   inherited WSRegisterClass;
  8.   RegisterWinControl;      
  9. .....
  10.  

D:\fpcupdeluxe\lazarus\lcl\widgetset\wscontrols.pp
Code: Pascal  [Select][+][-]
  1. procedure RegisterWinControl;
  2. const
  3.   Done: Boolean = False;
  4. begin
  5.   if Done then exit;
  6.   if not WSRegisterWinControl then
  7.     RegisterWSComponent(TWinControl, TWSWinControl);
  8.   Done := True;
  9. end;

Would it be a class var (probably did not exist back then) or unit implementation var (did exist) - this duplication would be caught immediately.

I repeat yet again: it is no big deal. But bursting with pride over it looks strange.
« Last Edit: September 26, 2022, 08:23:14 pm by Arioch »

BrunoK

  • Sr. Member
  • ****
  • Posts: 452
  • Retired programmer
Re: Evaluation of constant statements
« Reply #100 on: September 26, 2022, 09:28:02 pm »
Code: Pascal  [Select][+][-]
  1. class procedure TWinControl.WSRegisterClass;
  2. const
  3.   Registered : boolean = False;
  4. .....
  5.  
You are a ignorant guy.

Just debug the code and you'll see that it is called from at least about 10 places.

The prevention of calling inherited being put to use in many other places in the same context and cutting short complex operation with widget classes.

Before rambling on "I know all" theory, learn about virtual and dynamic methods and what they stand for. Then maybe, since you seem to be very 'cultured', some of what you shoot out may be relevant.

That code is involved in a process where measurable speedup was attained and nobody suggested a practical method to do it much differently than the way it is done currently (and was done when first created at the dawn of lazarus).

Study what happens in that part of the lazarus and put out a working prototype of better code. And I mean working prototype , not just some thrown out ramblings.
« Last Edit: September 26, 2022, 09:43:22 pm by BrunoK »

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: Evaluation of constant statements
« Reply #101 on: September 27, 2022, 12:57:42 am »
I am really puzzled at this point, is your misreading accidental or intentional ?

Quote from: Arioch
procedure RegisterWinControl;
   ...
where RegisterWinControl could've been called from, there seems to only be one single caller.

class procedure TWinControl.WSRegisterClass;

Just debug the code and you'll see that it is called from at least about 10 places.

Before we are overwhelmed by complexities "theory, learn about virtual and dynamic methods" can we, maybe, start with something simple, like comparing strings?

Can we agree whether the strings "procedure RegisterWinControl;" and "class procedure TWinControl.WSRegisterClass;" are equal or not?

Would we master this immdediate problem then we might make a try at rocket science of inheritance. I have much faith in us.

« Last Edit: September 27, 2022, 12:59:33 am by Arioch »

 

TinyPortal © 2005-2018