Recent

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Wishlist - (language evolution)
« Reply #30 on: July 16, 2022, 11:15:31 pm »
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.

There are limits to which a language can buck industry conventions, before it and the community around it becomes a laughing stock.

I'm happy to argue against the periodic newbie demand that braces be accepted as an alternative to begin/end keywords.

I'm prepared to tolerate the core team's refusal to even consider parameterised macros.

But for some to argue that consts being mutable is defensible is... well, indefensible.

The industry has eventually adopted or at least noted many of the language features introduced by Wirth in Pascal and Modula-2 (strong typing, modularisation) which in some cases might have been influenced by the UCSD and Borland Pascal implementations (plus of course Borland's Modula-2 implementation).

The C and C++ communities have also looked upon Wirth's use of const, and seen that it was good.

ALGOL had "own" variables. C, as a rather closer ALGOL derivative than Pascal can claim to be, has long had "static" variables.

FPC, plus the tattered remains of Borland, are well out of line conflating "const" and "static".

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 #31 on: July 16, 2022, 11:34:12 pm »
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.
In that example, it looks like you could have used "with RCC do" which, IMO, is clearer than "this" since what "this" is, isn't necessarily always clear, whereas "with" always names the record.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Wishlist - (language evolution)
« Reply #32 on: July 17, 2022, 12:24:40 am »
In that example, it looks like you could have used "with RCC do" which, IMO, is clearer than "this" since what "this" is, isn't necessarily always clear, whereas "with" always names the record.

Although "with" is deprecated, particularly when nested.

Some of the problems would be eliminated if it introduced a local constant representing the record it was abbreviating, but that was vetoed long ago.

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 #33 on: July 17, 2022, 12:41:46 am »
Although "with" is deprecated, particularly when nested.
Do you have a reference for "with" being deprecated ?... I use it all the time and, it is one of the things I miss the most when coding in C.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Wishlist - (language evolution)
« Reply #34 on: July 17, 2022, 09:57:00 am »
Do you have a reference for "with" being deprecated ?... I use it all the time and, it is one of the things I miss the most when coding in C.

I didn't so much mean deprecated as a language feature, as that whenever discussion has focussed on it there's a stream of people decrying it because of the ambiguity it introduces. As a particular case, if code in the scope of an object refers to a local field or property and also has a with referring to another object, mayhem will ensue if an RTL modification adds a clashing name to one or the other.

Which is why, in the past, there's been suggestions that a shortcut constant should be available in the block governed by the with.

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

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Wishlist - (language evolution)
« Reply #35 on: July 17, 2022, 10:51:40 am »
In that example, it looks like you could have used "with RCC do" which, IMO, is clearer than "this" since what "this" is, isn't necessarily always clear, whereas "with" always names the record.
The "this" concept doesn't share the ambiguity with "with", as "this" means the complete term that is assigned to.

Code: Pascal  [Select][+][-]
  1. RCC.APB2PCENR:= RCC.APB2PCENR or RCC_AFIOEN or RCC_IOPBEN or RCC_USART1EN;
would be identical with
Code: Pascal  [Select][+][-]
  1. RCC.APB2PCENR:= this or RCC_AFIOEN or RCC_IOPBEN or RCC_USART1EN;

+ very readable
+ reduced redundancy
+ less error-prone
= 100% Pascal

It's really a missing feature   ;)

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Wishlist - (language evolution)
« Reply #36 on: July 17, 2022, 11:34:32 am »
because of the ambiguity it introduces.
It's true that "with" can introduce ambiguities in a statement but, it very rarely happens when it's used correctly.

For instance in the example "with RCC do... ", RCC must be in the current scope and as a result very unlikely to address an unintended field.

Only one time, I've had a problem with the "with" statement and, if memory serves it is because Borland added some non-existent fields to a record used in the Winapi which just happened to be named the same as a local variable in my function.  In that case, I think the problem is with Borland sticking fields where they don't belong and not a problem with "with".

It's a very useful feature which I sorely miss when coding in C, particularly when using pointers to structures.

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

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Wishlist - (language evolution)
« Reply #37 on: July 17, 2022, 01:57:10 pm »
Code: Pascal  [Select][+][-]
  1. RCC.APB2PCENR:= this or RCC_AFIOEN or RCC_IOPBEN or RCC_USART1EN;
+ very readable

To you and you only (well and a handful of others maybe).

Just thinking ahead with upcoming inlined functions, and closures.... Not sure if I get the syntax right, but something like...
Code: Pascal  [Select][+][-]
  1. very_long_name_foo := this + function(bar: T)
  2.   begin
  3.     SetSomeVal(this + bar); // the outer captured "this" (and bar is also the outer "this")
  4.     result := CalcRes();
  5.     result := this + Val(); // "this" is result
  6.   end(this); // execute the function in place

Very readable indeed. Of course arbitrary limitations to the scoping rules could be made... Additional arbitrary rules are after all the best way to make a language clear and readable. ... not.


And you can always write your own version of "include" and inline it.
Code: Pascal  [Select][+][-]
  1. SetRegisterBits(RCC.APB2PCENR, RCC_AFIOEN or RCC_IOPBEN or RCC_USART1EN);
or
Code: Pascal  [Select][+][-]
  1. SetRegisterBits(RCC.APB2PCENR, [RCC_AFIOEN, RCC_IOPBEN, RCC_USART1EN]);

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: Wishlist - (language evolution)
« Reply #38 on: July 17, 2022, 02:15:58 pm »
There are limits to which a language can buck industry conventions, before it and the community around it

If you choose a language is not in the top 3 advocated languages for enterprise, plus one or two OSS darlings, then you are already bucking industry conventions.

Quote
becomes a laughing stock.

Such empty remarks are baseless, except as a whip to try to whip people into action. However the devels have gotten a thick skin after 20 years.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Wishlist - (language evolution)
« Reply #39 on: July 17, 2022, 02:46:24 pm »
Such empty remarks are baseless, except as a whip to try to whip people into action. However the devels have gotten a thick skin after 20 years.

Was it really that long ago that I appeared on the mailing list? :-)

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

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: Wishlist - (language evolution)
« Reply #40 on: July 17, 2022, 03:11:08 pm »
Such empty remarks are baseless, except as a whip to try to whip people into action. However the devels have gotten a thick skin after 20 years.
Was it really that long ago that I appeared on the mailing list? :-)

No, not yet. But there was always comp.lang.modula2.

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Wishlist - (language evolution)
« Reply #41 on: July 17, 2022, 03:15:03 pm »
While I don't think the "writable constant" gimmick should be corrected because it is anathema to industry trends, it is really embarrassing to tell a programmer who is learning Pascal that, in order to get a static variable, the programmer has to declare a writable "constant".

It's like saying, in Pascal, to draw a circle the programmer has to call the "rectangle" API. 

It really makes anyone wonder what other absurdities are part of the language.  The presence of such gimmicks, justifiably, reflect poorly on the language.

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Wishlist - (language evolution)
« Reply #42 on: July 17, 2022, 03:40:13 pm »
No, not yet. But there was always comp.lang.modula2.

:-) ...where I was fairly subdued for corporate reasons. OTOH M2 was a much smaller language than the monster into which Pascal has matured, although as I've said before I still feel that there's a really nice core language in there struggling to get out.

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

zamtmn

  • Hero Member
  • *****
  • Posts: 593
Re: Wishlist - (language evolution)
« Reply #43 on: July 17, 2022, 03:44:02 pm »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: Wishlist - (language evolution)
« Reply #44 on: July 17, 2022, 03:52:24 pm »
I'm missing simple things:
https://gitlab.com/freepascal.org/fpc/source/-/issues/39527

Just create the files if they don't exist in some prebuild event. If it is not needed, it shouldn't be in the compiler.

 

TinyPortal © 2005-2018