Recent

Author Topic: Question ?!!!!  (Read 37964 times)

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Question ?!!!!
« Reply #135 on: August 17, 2024, 03:43:43 am »
Does the below from the (Extended Pascal standard) really look "Pascal"?
Code: Pascal  [Select][+][-]
  1. program PathTest;
  2. import
  3.   SysUtils qualified only (GetEnvironmentVariable => GetEnv);
  4. begin
  5.   WriteLn(SysUtils.GetEnv('PATH'));
  6. end.
  7.  

No, does not look like Pascal to me. But is there a compiler that thinks its Pascal ?   Thaddy says GPC is a thing of the past, I have never had anything to do with it, so we have no convenient way to see if it compiles under GPC, my guess is 'NO'.

... then allow others to come in and add it behind the {$MODE DELPHI} and you can still boast your Delphi Compatibility. Make that a goal. 100%. Then people can directly move newer Delphi units to Free Pascal again.

The Two Thirds Rule :  two thirds of all programming work is maintaining existing code.  That applied when I was doing my degree, long ago, probably 'worse' now. Probably higher for code like compilers. Increasing the difference between MODE DELPHI and MODE FPC increases the boring, less attractive maintenance load. When we get to the point where no one wants to do it, the project starts to die (ie GPC). We do not want that !

Joanna
....... It’s strange how many low post accounts popup out of the woodwork in support for this awful idea?
Joanna, please clarify just what you consider to be an awful idea. A whole range of things are being discussed -
  • Warning a programmer that they seem to be assuming the value of a for-loop var is available after the loop.
  • Making sure that value is, in fact available.
  • Allowing the in-line declaration of a for-loop var.
  • Allowing impromptu in-line declarations.
  • Allowing code like RAID posted, apparently extracted from the Extended Pascal Standard.

I do not consider it an offense for a "low post" person to have an opinion on any of the above.

I believe its possible to download a legal copy of the original Turbo Pascal. And I guess Nickolas's original compiler (maybe J&W version) is still available, being published academic work (but not, I bet for x86_64). If you want a frozen in time, never to be changed Pascal, one of those would be the answer.

For the rest of us, change is part of life. Not change for change's sake but sensible, considered, discussed change that improves things. And we cannot discuss openly if accusations about being "low post" fly around.

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

MarkMLl

  • Hero Member
  • *****
  • Posts: 7999
Re: Question ?!!!!
« Reply #136 on: August 17, 2024, 08:22:40 am »
And I guess Nickolas's original compiler (maybe J&W version) is still available, being published academic work (but not, I bet for x86_64).

The P series (recursive descent) of compilers, or at least later derivatives thereof, are available. However I believe there was an unpublished interim compiler, based on the ALGOL-W (recursive ascent) compiler, which Wirth used between "throwing his toys out of the pram" as far as ALGOL-68 was concerned (May 1968) and being able to parcel work out to postgraduates (October 1968?) and it was this which was described in the earliest Pascal report which I think is somewhere in ETHZ's archive (I've seen it online, but it's not easily found).

The ALGOL-W compiler used manually-generated recursive ascent (i.e. bottom-up) parsing, it predated tools such as YACC. Modifying this, particularly when there are time constraints, is very hard work. I believe that that explains some of Pascal's apparent omissions (e.g. conditional expressions, dangling else): it's not that Wirth overlooked them, it's just that he didn't have time to resolve and test them before the anticipated release of a (usable) ALGOL-68 report.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Joanna from IRC

  • Hero Member
  • *****
  • Posts: 1198
Re: Question ?!!!!
« Reply #137 on: August 17, 2024, 03:02:50 pm »
@dbannon If it wasn’t clear from my previous posts I’m against declaring variables recklessly all over the place. I just thought of something about this inline variable creation nonsense. Does it allow the same variable name to be declared repeatedly throughout a procedure inside different begin end blocks too? What a mess.

I’m glad the fpc developers are not imitating delphi on this. Delphi appears to have sold out to bad ideas in hopes of being more popular.
✨ 🙋🏻‍♀️ More Pascal enthusiasts are needed on IRC .. https://libera.chat/guides/ IRC.LIBERA.CHAT  Ports [6667 plaintext ] or [6697 secure] channel #fpc  #pascal Please private Message me if you have any questions or need assistance. 💁🏻‍♀️

rvk

  • Hero Member
  • *****
  • Posts: 6572
Re: Question ?!!!!
« Reply #138 on: August 17, 2024, 04:06:10 pm »
Here is an article about some of the advantages about inline variables.
https://landgraf.dev/en/5-reasons-to-use-inline-variables-in-delphi/

Although some might not like it, it's in Delphi now.
I think it does have some advantages, if used correctly.
And if FPC wants to keep compatibility with {$mode delphi} it probably will get implemented. If not now, then in a few years or decade ;) Some other feature also had to wait years before being considered.
« Last Edit: August 17, 2024, 05:28:46 pm by rvk »

440bx

  • Hero Member
  • *****
  • Posts: 4727
Re: Question ?!!!!
« Reply #139 on: August 17, 2024, 04:29:27 pm »
Here is an article about some of the advantages about inline vari usedables.
https://landgraf.dev/en/5-reasons-to-use-inline-variables-in-delphi/
There are some advantages to inline variables but, the way they are implemented in Delphi (and C) is a poorly thought out solution to a structural deficiency in Pascal (C doesn't even have the deficiency inline variables attempt to compensate for.)

Ultimately, using "begin"/"end" as block delimiters is like using a stone as a hammer.  It can often be made to work but, it is far from what can be considered a satisfactory solution.  Copying mediocrity is not a good idea but, it's easier than copying genius.... <chuckle>


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

cdbc

  • Hero Member
  • *****
  • Posts: 1644
    • http://www.cdbc.dk
Re: Question ?!!!!
« Reply #140 on: August 17, 2024, 05:24:56 pm »
Hi
Regarding this:
Quote
Here is an article about some of the advantages about inline vari usedables.
https://landgraf.dev/en/5-reasons-to-use-inline-variables-in-delphi/

Me NO likey!

After reading that article, my eyes are hurting...
Please DO NOT implement such Bullocks in FPC!
Just my whole dollar's worth, this time...
Regards Benny
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE5 -> FPC 3.2.2 -> Lazarus 2.2.6 up until Jan 2024 from then on it's: KDE5/QT5 -> FPC 3.3.1 -> Lazarus 3.0

Joanna from IRC

  • Hero Member
  • *****
  • Posts: 1198
Re: Question ?!!!!
« Reply #141 on: August 17, 2024, 05:41:14 pm »
Quote
if FPC wants to keep compatibility with {$mode delphi} it probably will get implemented.
Why is it so important to keep compatibility with Delphi? Wouldn’t all the delphi users who want to switch to Lazarus have joined us by now?

If the developers of Delphi are doing stupid things that violate fundamental rules of pascal there is no need to follow them. Do people even use Delphi anymore? I can’t find a chat channel or forum for it.
✨ 🙋🏻‍♀️ More Pascal enthusiasts are needed on IRC .. https://libera.chat/guides/ IRC.LIBERA.CHAT  Ports [6667 plaintext ] or [6697 secure] channel #fpc  #pascal Please private Message me if you have any questions or need assistance. 💁🏻‍♀️

Thaddy

  • Hero Member
  • *****
  • Posts: 16138
  • Censorship about opinions does not belong here.
Re: Question ?!!!!
« Reply #142 on: August 17, 2024, 05:43:20 pm »
Thaddy says GPC is a thing of the past, I have never had anything to do with it, so we have no convenient way to see if it compiles under GPC, my guess is 'NO'.
I never wrote it as such.  I merely hinted at such.
If I smell bad code it usually is bad code and that includes my own code.

alpine

  • Hero Member
  • *****
  • Posts: 1289
Re: Question ?!!!!
« Reply #143 on: August 17, 2024, 05:54:58 pm »
Here is an article about some of the advantages about inline vari usedables.
https://landgraf.dev/en/5-reasons-to-use-inline-variables-in-delphi/
There are some advantages to inline variables but, the way they are implemented in Delphi (and C) is a poorly thought out solution to a structural deficiency in Pascal (C doesn't even have the deficiency inline variables attempt to compensate for.)
Specifically for what structural deficiency in Pascal you're talking about? In C variables are inline since the language was invented. Only the for(stmnt;...) ability to contain declarations was added later.
Ultimately, using "begin"/"end" as block delimiters is like using a stone as a hammer.  It can often be made to work but, it is far from what can be considered a satisfactory solution.  Copying mediocrity is not a good idea but, it's easier than copying genius.... <chuckle>
Begin and end aren't "block delimiters". Check your Pascal terminology.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

LV

  • Full Member
  • ***
  • Posts: 153
Re: Question ?!!!!
« Reply #144 on: August 17, 2024, 06:16:32 pm »
In Delphi, you have two options: 1) You can use inline variables. 2) Or you can declare them outside the begin...end block as usual. It's up to you to decide which one you prefer. Am I wrong?

rvk

  • Hero Member
  • *****
  • Posts: 6572
Re: Question ?!!!!
« Reply #145 on: August 17, 2024, 06:22:05 pm »
Quote
if FPC wants to keep compatibility with {$mode delphi} it probably will get implemented.
Why is it so important to keep compatibility with Delphi?
Why have a Delphi mode at all then?

Compatibility.
Switching from Delphi to FPC will become increasingly more difficult if the whole code is riddled with inline variables. I'm not saying it's a good thing but if you boast about compatibility you also need to maintain that compatibility.

Curt Carpenter

  • Hero Member
  • *****
  • Posts: 559
Re: Question ?!!!!
« Reply #146 on: August 17, 2024, 06:25:44 pm »
Is it true then that in Delphi I can have a variable, say "I", declared multiple times in a single procedure, once before the first "begin" and then possibly dozens of times within the body of the procedure itself, with each "I" possibly having a different type?

If so:  sounds exciting.

Maybe it would be good to attach a "version rider" on the Delphi compatibility statement:  eg.  "Compatible with Delphi version 8 and earlier."


rvk

  • Hero Member
  • *****
  • Posts: 6572
Re: Question ?!!!!
« Reply #147 on: August 17, 2024, 06:32:50 pm »
Is it true then that in Delphi I can have a variable, say "I", declared multiple times in a single procedure, once before the first "begin" and then possibly dozens of times within the body of the procedure itself, with each "I" possibly having a different type?
That's only possible if you declare it within a begin/end block (or for loop). Otherwise the variable is valid from definition until the end of the current block and you can't redeclare it (at least I think you can't redeclare but I don't have D10.3 to check).

https://docwiki.embarcadero.com/RADStudio/Athens/en/Inline_Variable_Declaration

440bx

  • Hero Member
  • *****
  • Posts: 4727
Re: Question ?!!!!
« Reply #148 on: August 17, 2024, 06:37:30 pm »
Begin and end aren't "block delimiters". Check your Pascal terminology.
The simplest first.  "begin"/"end" become block delimiters when inline variables are implemented.  They delimit the scope/existence of the variables.

Specifically for what structural deficiency in Pascal you're talking about? In C variables are inline since the language was invented.
The structural deficiency in Pascal is that there is no way to create inline groups of statements (or independent blocks).  Pascal offers nested functions/procedures but that is _not_ a good solution for groups of statements that accomplish a particular task that is only done once in a function/procedure.  The reason nested functions/procedures are not a good solution in that case is because the group of statements is not inline thus forcing the programmer to divert his/her attention to another place to see what code is executed.

A complete implementation of Pascal structural concepts would include having groups of statements (what functions and procedures are) that are inline simply because they are not executed anywhere else yet, they should be identified as performing a well defined logical task within the function (which is usually a very small task.)

Creating a separate function/procedure for such groups of statements is highly inappropriate because not only it diverts the programmer's attention to another location but, it also implies the code is executed in more than one place (that's the primordial reason a function/procedure should be created, re-using the code) which is false in those situations.

In addition to contributing to a form of spaghetti code (go someplace, read some code, go back to the original place, read more code, go to some other place to read some more code that should have been inline), it also contributes to "jigsaw puzzle" programming, the breaking of a program in thousands of tiny pieces the programmer has to mentally put back together.  (Very unfortunately, an activity that is openly encouraged... demonstrating a severe lack of understanding about basic programming principles.)


Lastly, the reason this is related to inline variables is because, it is extremely common to need a temporary variable which is useful in a very limited number of statements and have no business being declared and visible in the entire function/procedure.  This is the problem inline variables solve in a very deficient way.   Why design a good solution when a hack will do ?... it's so much easier to copy mediocrity (in this case from C.)

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

Weiss

  • Full Member
  • ***
  • Posts: 183
Re: Question ?!!!!
« Reply #149 on: August 17, 2024, 07:07:04 pm »
if decorated generals would allow low post count (and complete rookie) to speak, than I must say, the way inline declaration implemented in Delphi appear to make sense. Yes, I have followed the links and read articles on first page. But I have mixed feelings about it.

If your begin-end block is short and concise, then inline declaration (as implemented in Delphi) is remembered easily, for readability. Especially if this is a single-use disposable variable, which is utilized immediately. At first look, Delphi implementation kind of get a nod of approval. But then, for such short block of code, traditional Pascal declarations are only a few lines of code above. It is just as clear, and convenient.

If that same begin-end block is long, and has multiple nested begin-ends, than locally declared variable is harder to keep in mind, and harder to find. In such case, variable name should be sufficiently long and self-explaining probably? Apparently, long and convoluted blocks of code is the only place where such locally-declared variables might be needed. But, still no go, in my opinion. For such long procedure, you know where your declarations are, along with your inline "what and why" comments.

I myself mused about inline declarations since FPC is not my first programming language. In C# for example, variable declared on the fly all the time. I kind of used to that style. But it took me no time to adopt the clarity of Pascal, wholeheartedly. I normally not just declare something, I always comment what is it, where used and why we need it etc. I do it for myself, it is like a documentation almost. My 2c

 

TinyPortal © 2005-2018