Recent

Author Topic: Wishlist - (language evolution)  (Read 5857 times)

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Wishlist - (language evolution)
« Reply #15 on: July 16, 2022, 12:05:27 am »
Something along the lines of "zerolocals" would be great to have.  One directive and done!  I would even like to see it as as default behavior for all functions/procedures based on some "modeswitch" or something similar.
I think a modeswitch to activate local var initialization for the whole unit would be more useful. And I'd would rather use it for productive code to make it more fail safe. (But probably wouldn't for performance considerations~).


====
6. I'd wish for static local variables to replace the misleading writable typed constant stuff (the latter should be default off in mode objfpc).

So

Code: Pascal  [Select][+][-]
  1. procedure Foo;
  2. var
  3.   CallCount: Integer = 0; static;
  4. begin
  5.   CallCount:= CallCount +1;
  6.   //...
  7. end;

Although the variable could be just placed outside the function, for the sake of language completeness it should be available.


====
7. I'd wish for a placeholder for the left side of an assignment that can be used in the right side. A suitable keyword could be "this".

Code: Pascal  [Select][+][-]
  1. CallCount:= this + 1;
  2. Form1.Image1.Picture.Bitmap.Width:= this + 100;
  3. SomeVal:= this + k / this;


ccrause

  • Hero Member
  • *****
  • Posts: 843
Re: Wishlist - (language evolution)
« Reply #16 on: July 16, 2022, 08:22:58 am »
====
6. I'd wish for static local variables to replace the misleading writable typed constant stuff (the latter should be default off in mode objfpc).
Indeed, I wish for the keyword const to simply mean runtime constant, in all cases  :o

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Wishlist - (language evolution)
« Reply #17 on: July 16, 2022, 08:42:13 am »
Quote
The problem is that often the value is displayed in decimal instead of hex
Maybe the debugger should detect those values, and default to show them in hex....

At the very least, an option to change the default from dismal to- well, basically anything else would be extremely useful.

Also an option to use some different character for the overall delineation of strings to avoid confusion when looking at something which is itself quoted... surely there's some suitable UTF-8 character for this?

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

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Wishlist - (language evolution)
« Reply #18 on: July 16, 2022, 10:34:02 am »
But I though I made it very clear, that I had responded to ONE (and just that one) reason, that you had given at one point.
And any response to (or looking at) my response that ignorers this context, will of course not find any sense in my response.
Honestly, by now, I don't think I know what it is we're arguing about.

Keeping things simple, I'd like to have the compiler provide some facility to tell it to initialize all local variables to binary zeroes.

Among many reasons are: it's nice to have variables automatically initialized to an easily recognizable, consistent value.  The value "binary zeroes" is, almost always, the natural, most useful, initial value.

It's that simple.  Any value that is not binary zeroes is simply not as useful and identifiable as an initial value as binary zeroes.



« Last Edit: July 16, 2022, 10:36:45 am by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

dseligo

  • Hero Member
  • *****
  • Posts: 1177
Re: Wishlist - (language evolution)
« Reply #19 on: July 16, 2022, 10:36:46 am »
====
6. I'd wish for static local variables to replace the misleading writable typed constant stuff (the latter should be default off in mode objfpc).
Indeed, I wish for the keyword const to simply mean runtime constant, in all cases  :o

I believe that there is a lot of code which uses const for static variables and such change would break that code.
So I think there is no chance for this to happen.

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Wishlist - (language evolution)
« Reply #20 on: July 16, 2022, 10:45:35 am »

Thaddy

  • Hero Member
  • *****
  • Posts: 14159
  • Probably until I exterminate Putin.
Re: Wishlist - (language evolution)
« Reply #21 on: July 16, 2022, 11:24:43 am »
And untyped const should always stay there: the compiler uses that at compile time and simply uses its value directly, without any storage. A typed const is always stored: in {$J-} state in a readonly section and in {$J+} state in a writable section.
So that part is already covered, albeit with different semantics compared to other languages, but that has always been the case.
static local variables - or global - are simply typed consts. The difference between local const and local typed const is that the latter is stored outside of the procedure in a section and does not use little stack space apart from a reference. A local untyped const will be replaced by its value at compile time so does not use any stack space at all.
« Last Edit: July 16, 2022, 11:36:53 am by Thaddy »
Specialize a type, not a var.

ccrause

  • Hero Member
  • *****
  • Posts: 843
Re: Wishlist - (language evolution)
« Reply #22 on: July 16, 2022, 02:30:25 pm »
And untyped const should always stay there: the compiler uses that at compile time and simply uses its value directly, without any storage. A typed const is always stored: in {$J-} state in a readonly section and in {$J+} state in a writable section.
So that part is already covered, albeit with different semantics compared to other languages, but that has always been the case.
static local variables - or global - are simply typed consts. The difference between local const and local typed const is that the latter is stored outside of the procedure in a section and does not use little stack space apart from a reference. A local untyped const will be replaced by its value at compile time so does not use any stack space at all.
Thank you for illustrating exactly why I don't like the current situation regarding the multi-faceted nature of const.  I wish for the simplicity where const simply means "this value must not be changed".  The compiler is then free to handle and enforce this contract any way it sees fit - including deciding when storage is required.

There is already an alternative mechanism for declaring a variable with an initial value, no need to tack this use case to const.  Granted, this is a later development in Pascal, but should we carry the baggage of missing/poor original implementation forever?  I see no use for treating a typed const any different to an untyped const.  The programmer just informed the compiler the type associated with the value, rather than relying on the compiler to infer the type based on language rules.

There isn't a Pascal alternative to specify a static local variable, hence my support for a new keyword to indicate this functionality.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Wishlist - (language evolution)
« Reply #23 on: July 16, 2022, 02:47:09 pm »
Thank you for illustrating exactly why I don't like the current situation regarding the multi-faceted nature of const.  I wish for the simplicity where const simply means "this value must not be changed".  The compiler is then free to handle and enforce this contract any way it sees fit - including deciding when storage is required.

Broadly agreed. I'd suggest that an important detail is that misuse of const as var-static could be detected and warned as deprecated by the compiler, so it would break existing code to a far lesser extent than other changes (e.g. the one to FileExists()) that have been slipped into the language and runtimes.

It is specious to argue that because Borland implemented const as mutable in Turbo Pascal then it must have been what Wirth envisaged or intended, since that is definitely not something that was in Pascal /ex/ /cathedra/, and I have no reason to believe that he approved of Borland's hack by incorporating it in his later languages. In fact Wirth's definition of Modula-2 included the statement that constants would always be evaluated by the compiler, which I feel argues strongly that he considered them to be immutable.

Static variables are undeniably useful, they are good style since they avoid promoting scope-limited locals to globals, and they continue the semantics of ALGOL's "own" keyword. But I'm sufficiently cautious of the existing syntax to always comment its usage as "(* Static variable *)", just as I'm sufficiently cautious to annotate exit if used inside a try-finally block.

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

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Wishlist - (language evolution)
« Reply #24 on: July 16, 2022, 03:09:04 pm »
There isn't a Pascal alternative to specify a static local variable, hence my support for a new keyword to indicate this functionality.
I wholeheartedly agree with that.

It's ludicrous that an identifier declared as "const" can be modified.  It renders "const" meaningless since it obviously does not mean "constant" in that context.

Unfortunately, it seems that if FPC allows one way of implementing something then, a better and clearer implementation will not be considered (unless Delphi does it.)

Horrible ideas get perpetuated while new ones, no matter how good they are, get fought against, tooth and nail.  No wonder progress is slow.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 14159
  • Probably until I exterminate Putin.
Re: Wishlist - (language evolution)
« Reply #25 on: July 16, 2022, 03:30:29 pm »
A "static local variable" is exactly the same as a typed const in{$J+} mode. It is just semantics. Shut up  >:D.
Even languages that use the expression "static local variable" such constructs are always just a reference and stored outside local. On this topic nothing needs to change. This is wildly borderline.....
« Last Edit: July 16, 2022, 03:34:17 pm by Thaddy »
Specialize a type, not a var.

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Wishlist - (language evolution)
« Reply #26 on: July 16, 2022, 04:03:33 pm »
Thaddy, I see you are having one of your "good days".

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: Wishlist - (language evolution)
« Reply #27 on: July 16, 2022, 04:52:40 pm »
Quote
and, are the "default" values always binary zeroes ?
Is all zero always the correct behaviour?
Code: Pascal  [Select][+][-]
  1. type
  2.   TFoo = (foo1 = 11, foo2 = 21);
  3.   TBar = 100..110;
  4. var
  5.   aFoo: TFoo;
  6.   aBar: TBar;

Initializing aFoo/aBar with zero creates an invalid value. And invalid values can lead to unpredictable behaviour. Upgrade your compiler, or change some settings and the behaviour of your app may change unexpectedly.

Default always initializes to 0 even if that value is not valid for the given type.

There could even be types for which no unambiguous default exists:

Code: Pascal  [Select][+][-]
  1. TTest = record
  2.   case Boolean of
  3.     True: (a: -10..-5);
  4.     False: (b: 5..10);
  5. end;

Thus default simply initializes to 0 even if it would be wrong for the type.

6. I'd wish for static local variables to replace the misleading writable typed constant stuff (the latter should be default off in mode objfpc).

So

Code: Pascal  [Select][+][-]
  1. procedure Foo;
  2. var
  3.   CallCount: Integer = 0; static;
  4. begin
  5.   CallCount:= CallCount +1;
  6.   //...
  7. end;

No. There is a way to declare such a variable and thus there won't be another as unintuitive as the existing way may seem.

7. I'd wish for a placeholder for the left side of an assignment that can be used in the right side. A suitable keyword could be "this".

Code: Pascal  [Select][+][-]
  1. CallCount:= this + 1;
  2. Form1.Image1.Picture.Bitmap.Width:= this + 100;
  3. SomeVal:= this + k / this;

No.

And at least for cases that don't involve properties you can use the C-style operators or for CallCount you could simply use Inc as well.

ccrause

  • Hero Member
  • *****
  • Posts: 843
Re: Wishlist - (language evolution)
« Reply #28 on: July 16, 2022, 07:29:34 pm »
A "static local variable" is exactly the same as a typed const in{$J+} mode. It is just semantics.
I prefer const to always mean immutable as noted by Mark.  My intention is not to introduce redundant syntax (although it my appear so), but to clean up the Pascal language to the point where explaining what const means in a program (whether a const section, const parameter or typed const (local or global)) can be described in a simple, short sentence.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Wishlist - (language evolution)
« Reply #29 on: July 16, 2022, 10:03:57 pm »
A "static local variable" is exactly the same as a typed const in{$J+} mode. It is just semantics. Shut up 
It's exactly the same, but the syntax is highly misleading. One of Pascals strength is it's readability. And this is a huge negative example that I would rather expect in C (no insult). And I really think this is a quirk that should be cleaned up. It's not an other call for a fancy new feature, it's just to remove the skeleton from the closet.


6. I'd wish for static local variables to replace the misleading writable typed constant stuff (the latter should be default off in mode objfpc). [...]

No. There is a way to declare such a variable and thus there won't be another as unintuitive as the existing way may seem.

The problem is less the unintuitive usage, but (as stated above) the bad readibility. I would nobody recommend to use a writable typed constant because of that and I also never use it myself.

It's also easy to draw wrong conclusions. Lately I translated a unit from C with typed constants, using the typed constant syntax was a mistake I made just because of the misleading syntax. A (ugly) typecast in the constant would have been the correct way.
In Delphi as far as I know the writable typed constant is disabled by default, but I'm not sure (don't have Delphi).

7. I'd wish for a placeholder for the left side of an assignment that can be used in the right side. A suitable keyword could be "this". [...]

No.

And at least for cases that don't involve properties you can use the C-style operators or for CallCount you could simply use Inc as well.
The c-style operators are very ugly, so I wouldn't use it. I think a "this"-syntax would be very pascal'ish and very readable.

Lately when programming for a microcontroller I had a lot of statements like the following to access hardware registers, the register name mostly has to be repeated, as only some bits are to be changed. There the "this"-syntax would be very helpful.
Code: Pascal  [Select][+][-]
  1.   // Enable clocks
  2.   RCC.APB2PCENR:= RCC.APB2PCENR or RCC_AFIOEN or RCC_IOPBEN or RCC_USART1EN;
The c-style doesn't work here (and I wouldn't us it anyways). But repeating the register name is error-prone when doing copy and past as there are often very similar names like RCC.APB1PCENR and RCC.APB2PCENR.
« Last Edit: July 16, 2022, 10:07:24 pm by kupferstecher »

 

TinyPortal © 2005-2018