Question ?!!!!

[MarkMLl]

I'm taking it upon myself to respond since I was the one who labelled a Delphi inline variable example as "not Pascal". But first, I want to say that I sympathise with your point about heredocs, and I specifically sympathise with your using that term since some means of embedding (in particular) SQL (etc.) in the body of a program, where it can be read in the context of the program's flow, is sorely lacking.

I see a lot of "it's not Pascal". Who determines if it's "Pascal"? A group of individuals? We did not invent Pascal, so how can you say something is not "Pascal"?

Is Delphi not "Pascal"? They are the ones who own Pascal. They're the original, they're the ones who pioneered it and added inline variables and type inference, etc.

We must go back to the roots.

Delphi (i.e. Borland, as was) does not own Pascal. FPC does not own Pascal. The ISO has some claim to own Pascal by virtue of their standard, but it was always looked at askance by the community since it was published at a time when implementations like UCSD were dominant but largely ignored them.

I am not entirely happy with a lot of the stuff that has been stuffed into Pascal implementations over the last few years. I don't particularly want to single anything out for criticism since I don't want to be seen as criticising the developers, but by now there are far too many things in the base language. However my specific complaints about this example

Code: Pascal  [Select][+][-]

1.     procedure Test;
2.     begin
3.       var I := 22;
4.       ShowMessage (I.ToString);
5.     end;
6.  

are

* It appears to fly in the face of Wirth's dictum that all declarations should precede begin.

* That however is not its intention, which is that it applies to precisely the following statement.

* But the lack of any form of enclosure obfuscates that.

* The declaration could have been preceded by a begin (and the statement followed by a mandatory end), but that would again fly in the face of "declarations precede begin" and "a single statement need not be encapsulated by begin...end" (the latter being something upon which Wirth later recanted, but not in Pascal).

* The lack of type information hinders both the compiler and the reader. I could quote a related warning from K&R here, but instead would present

Code: Pascal  [Select][+][-]

1.     procedure Test;
2.     begin
3.       var I := 22;
4.       ShowMessage ((I - 255).ToString);
5.     end;
6.  

* Should I be considered signed or unsigned? Should it wrap or raise an exception? If it wraps, at what point? And so on.

So, without trying to sound too Jesuitical, we have to distill certain principles from what Wirth himself (ably assisted by Jensen) wrote about Pascal, and from extensions made to the language by UCSD, ISO, Borland et al. provided that they do not directly fly in the face of the language Wirth designed.

First is that all declarations appear in this pattern:

Code: [Select]

<header>

<declarations>

<statements>

As far as I can see, Wirth defined it like that at least in part to distinguish it from ALGOL, of which he was washing his hands for political reasons (I've written about that elsewhere). ALGOL declared variables inside the statement block, Pascal does not: like it or not, departing from that is Not Pascal.

Wirth defined that all variables had an associated type specified after the variable name. That was bleeding-edge stuff: most ALGOL implementations were only just waking up to the necessity of specifying whether a variable was a float or an integer let alone to the possibility of strings, structured records, booleans, and integers of different sizes. My position is that Wirth was excessively tolerant of automatic type transfers (casts), and while he subsequently tightened his compatibility rules up doing so was Not Pascal.

And so on.

So, where does that leave us? I would suggest that while the example I gave above was Not Pascal (for the reasons I gave) something like this would be far closer to Wirth's intent:

Code: Pascal  [Select][+][-]

1.     procedure Test;
2.     begin
3.       with I: integer= 22 do
4.         ShowMessage (I.ToString);
5.     end;
6.  

or alternatively

Code: Pascal  [Select][+][-]

1.     const a: integer= 22;
2. ...
3.     procedure Test;
4.     begin
5.       with I= a do // Inference allowed since consatnt's type known
6.         ShowMessage (I.ToString);
7.     end;
8.  

Those are, arguably, Pascal. However even if he had wanted to define the language like that Wirth couldn't have implemented it: he was working with the ALGOL-W compiler based on recursive ascent, and when one compares the /syntax/ of Pascal with that of ALGOL-W one finds that it is very similar: modifying the internal operation of a recursive ascent parser is arduous in the extreme, and Wirth was convinced that he only had a few months to get Pascal demonstrable in order to preempt ALGOL-68.

He was of course wrong in that, but that can be the subject of another rant.

MarkMLl

[rvk]

Code: Pascal  [Select][+][-]

1.       ShowMessage ((I - 255).ToString);
2.  

(I - 255).ToString .....? That doesn't look like Pascal

Helpers are also not part of the Pascal standard 
Object Pascal itself is also not Pascal standard.
So... There are dialects for that in which you can deviate from what Wirth originally intended.

Code: Pascal  [Select][+][-]

1. begin
2.   var I := 22;

But this bothers me too. At least it should have a type definition. Otherwise we can just go back to Basic

[MarkMLl]

Helpers are also not part of the Pascal standard 
Object Pascal itself is also not Pascal standard.
So... There are dialects for that in which you can deviate from what Wirth originally intended.

Agreed. Supersets etc., but not Pascal per se.

Code: Pascal  [Select][+][-]

1. begin
2.   var I := 22;

But this bothers me too. At least it should have a type definition. Otherwise we can just go back to Basic

At about the same time you posted I changed my example to allow inference where the type was fully defined.

MarkMLl

[dbannon]

I see a lot of "it's not Pascal". Who determines if it's "Pascal"? A group of individuals?

• Standard Pascal (ISO 7185) https://www.standardpascal.org/iso7185.pdf
• ISO Extended Pascal Standard (ISO 10206) https://standardpascal.org/iso10206.pdf

The point is, we use Pascal here because we like it. If it changes too much, maybe we won't like it anymore ?   ;D

You ask: submit a patch and they may accept it.

Yep, I think the evidence is not too much change is initiated from outside the core group. But remember, that core group would need to maintain the content of your patch long after you have wondered off using C#. So, they need a good reason to accept it AND like the way its done. I spent a long time here arguing that the default name of a particular Linux library was wrong, in the end I gave up. While I am unhappy about that, I accept its their call.

Interestingly, Delphi does not come up when you google for "Pascal Compiler", I am not sure if they make any statements about ISO comparability (I have not used it since Delphi 2). Delphi was always been presented as "Delphi" (that incidentally uses a Pascal syntax).

GNU Pascal does claim ISO compliance. It does permit something like the line that Mark so objected to, labeling it "an extension".

Code: Pascal  [Select][+][-]

1.      begin
2.        var Bar: Integer;  { GNU Pascal extension }
3.        Bar := 42
4.      end.

That is, IMHO, less scary but I'd still vote (if I had a vote) against it. But I'd vote for the in line declaration in a "for loop" because it solves a real need.

Davo

[MarkMLl]

Yep, I think the evidence is not too much change is initiated from outside the core group.

So much has been shoehorned into the base language that... well, I hesitate to say that it's unmaintainable but all the evidence is that the barriers to being able to do something useful get higher every year.

That is, IMHO, less scary but I'd still vote (if I had a vote) against it. But I'd vote for the in line declaration in a "for loop" because it solves a real need.

I agree, and it /removes/ complexity from (the definition of) the language since the availability of something like this

Code: Pascal  [Select][+][-]

1. for i: integer= 0 to 9 do
2.  

means that it would be possible to add a straight warning that, while legal, /not/ having an inline variable might result in unexpected behaviour.

It's interesting: looking at that and my earlier example

Code: Pascal  [Select][+][-]

1. with I: integer= 22 do
2.   ShowMessage (I.ToString);
3.  

both relate to clauses terminated by "do"... it's almost as though the language as defined by Wirth was begging for improvement in that specific area but it was one of those he had to leave unfinished.

MarkMLl

[dbannon]

I agree, and it /removes/ complexity from (the definition of) the language since the availability of something like this

Code: Pascal  [Select][+][-]

1. for i: integer= 0 to 9 do
2.  

means that it would be possible to add a straight warning that, while legal, /not/ having an inline variable might result in unexpected behaviour.

For the sake of the argument, would you assume 'most' new code would use an in-line var to index the for-loop if allowed ? 

I ask because often, I will re-use a variable in a longer method because I figure its kinder on memory but from this discussion, seems the compiler can do a better job if each 'role' has its own variable ? I'm thinking assembly does not really have vars, it has memory locations and registers, am I being silly here ?

Code: Pascal  [Select][+][-]

1. with I: integer= 22 do
2.   ShowMessage (I.ToString);
3.  

I don't see the compelling case for change with a "with" statement to be honest.

Davo

[MarkMLl]

For the sake of the argument, would you assume 'most' new code would use an in-line var to index the for-loop if allowed ? 

I ask because often, I will re-use a variable in a longer method because I figure its kinder on memory but from this discussion, seems the compiler can do a better job if each 'role' has its own variable ? I'm thinking assembly does not really have vars, it has memory locations and registers, am I being silly here ?

I believe that that is a reasonable expectation: after all, C programmers adopted that (once available) almost universally and even Pascal programmers learnt that a loop control variable /had/ to be local once the compilers started insisting upon it.

And since in the statement(s) that follow it is effectively a read-only variable there would really be no need to have it in memory: I don't believe that there's even a valid reason to want to be able to take its address.

I don't see the compelling case for change with a "with" statement to be honest.

I believe that something's necessary in order to preserve Pascal's "header-declarations-code" structure. I've used with here since I've also (I think recently) mentioned using a placeholder variable in a with statement to represent what is being "shortcutted-to" rather than risking the user (or, worse, compiler) guessing, which I think makes it an obvious choice.

In addition, in this context it is necessary to have a variable in memory which can have its address taken etc., and since a temporary variable might be a non-shortstring or dynamic array etc. there might be an implied try-finally structure: a with here might be a useful hint to the compiler that it needs to consider this.

MarkMLl

[Joanna]

My conclusion from all of this is that the people who make Delphi have gotten desperate for acceptance from non pascal programmers and have changed delphi into something that is truly no longer pascal and definitely should not be imitated. It’s strange how many low post accounts popup out of the woodwork in support for this awful idea?

Many new features have been added to pascal which have greatly improved its functionality. However it would be foolish to stuff every new ridiculous idea that comes along into the fpc compiler. People who like other languages are never going to switch to pascal because pascal tried to imitate other languages. It will only ruin things for people who use pascal.

@440bx the amount of complexity required to check if a variable has been initialized in all cases would probably make compiler very bloated.

@markml I enjoy reading some things on Wikipedia despite of it being very biased on certain issues. Thanks for link , it’s a bit difficult for me to understand though.

[MarkMLl]

My conclusion from all of this is that the people who make Delphi have gotten desperate for acceptance from non pascal programmers and have changed delphi into something that is truly no longer pascal and definitely should not be imitated. It’s strange how many low post accounts popup out of the woodwork in support for this awful idea?

Many new features have been added to pascal which have greatly improved its functionality. However it would be foolish to stuff every new ridiculous idea that comes along into the fpc compiler. People who like other languages are never going to switch to pascal because pascal tried to imitate other languages. It will only ruin things for people who use pascal.

Frankly, I agree with you. But for a very long time Delphi has been targeted at a part of the market that was previously served by "4GLs" i.e. dBase and so on... and just look at who happened to buy up dBase and its owners (Ashton-Tate) at one point.

"The Delphi Language", aka Object Pascal, is undoubtedly better-conceived than most if not all other 4GLs which were basically extended BASICs. But there are so many odd decisions that have gone into it over the years: odd decisions from which this community cannot easily disentangle itself.

@440bx the amount of complexity required to check if a variable has been initialized in all cases would probably make compiler very bloated.

@markml I enjoy reading some things on Wikipedia despite of it being very biased on certain issues. Thanks for link , it’s a bit difficult for me to understand though.

Don't worry, /I/ find that difficult to understand... which really was the point I was trying to make. In practice the decision cannot be made inside the compiler: it's basically Turing's "Halting Problem".

So it's been bug reported, and that's about all we can do pending attention from people who understand the innards of the compiler.

MarkMLl

[Joanna]

I think that some people get the idea that the ide, debugger {And ai }should practically write programs for them. This is not the case. It’s still necessary to check and test code for correctness’s yourself.
This reminds me of a story I once heard about some people who mistook cruise control for autopilot and all of them went into the back of the van to relax on some beanbags as it cruised down the road... it didn’t stay on the road for very long..

[MarkMLl]

Some number of years ago, there was a programming tool called The Last One which was supposed to render everything else obsolete. There was also something similar called (IIRC) PCL which existed only as a back-cover advert on some high-end computer mags.

I do, of course, mean in the early 80s. I would speculate that there have been more distinct computer languages engendered since then than there were before.

MarkMLl

[Thaddy]

Code: Pascal  [Select][+][-]

1.      begin
2.        var Bar: Integer;  { GNU Pascal extension }
3.        Bar := 42
4.      end.

GNU Pascal is written in C, so that would probably easily have matched the C construct.
I never liked GNU Pascal and it is - almost, not officially - abandonware, unlike FPC.
There are more constructs that more or less reveal its true heritage, being Pascalized C syntax.
GNU Pascal’s reliance on GCC might have limited its development and adaptability. FreePascal’s approach has certainly proven successful, providing a robust and actively maintained Pascal compiler.
IOW we are lucky that we do have Pascal compiler developers instead of just one.
And they tend to come up with some unique features over the years.

[Raid]

...

Code: Pascal  [Select][+][-]

1. for i: integer= 0 to 9 do
2.  

...

Code: Pascal  [Select][+][-]

1. with I: integer= 22 do
2.   ShowMessage (I.ToString);
3.  

I've moved back on to C#, and as much as I think those would be nice options (especially the 'with'), and of course type inference with a number could be a 'Signed Integer' (32bit) like in C# and Java, and 'float' for a decimal number, it's not gonna be Delphi compatible. I have sorrow towards my childhood language, especially Free Pascal/Lazarus which I've used for many years. Free Pascal can no longer boast Delphi Compatibility, not even with {$MODE DELPHI}, and it's not longer a "Free Alternative" to Delphi.

I know you understand, as you've stated that you disagree with many things that were introduced, but those were added for the sake of Delphi Compatibility I'm sure.

The Extended Pascal Standard states you can use a type from another variable/constant etc. This is basically stepping into type inference category before it became a thing.

Does the below really look "Pascal"?

Code: Pascal  [Select][+][-]

1. program PathTest;
2.  
3. import
4.   SysUtils qualified only (GetEnvironmentVariable => GetEnv);
5.  
6. begin
7.   WriteLn(SysUtils.GetEnv('PATH'));
8. end.
9.  

That's from the Extended Pascal standard. My point is, what "Looks" Pascal? Why stop the Delphi compatibility? If it's due to manpower/man hours, 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.

But anyway, I know what I'm saying will most likely not change anything so the language aside, I wish everyone to be well, and to take care.

See you everyone.

[MarkMLl]

I have sorrow towards my childhood language, especially Free Pascal/Lazarus which I've used for many years.

I'm afraid that during my childhood years punched cards were a rarity, and KSR/ASR Teletypes were in use for some years after I graduated.

Apart from that I can assure you that I sympathise, but can't offer any constructive suggestions. Leaving aside current professional involvement, there's a few more things I want to explore before I "pop my clogs" and I feel that provided that I use fairly naive Pascal (which includes avoiding the sort of ISO Extended monstrosity you quoted, or at least documenting what it does and why I'm using it) the published techniques will be reusable in just about any language.

From my POV, Pascal is enormously significant because it demonstrated the importance of variable and expression types (which Wirth later tightened up further), and its successor Modula-2 demonstrated that strong typing could be extended across program modules. The fact that I continue to use it is entirely pragmatic ("can't teach an old dog new tricks") but is strongly influenced by the extremely competent Lazarus IDE.

MarkMLl

[Joanna]

. Why stop the Delphi compatibility? If it's due to manpower/man hours, 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 fpc developers probably have more important features to work on. Why divert precious resources to implement such a horrible unpascal idea?