Innovation in the language

[AccurateAlx]

We have it already, but the actual keywords are "try try" and "end finally":

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

1.   try try
2.   except
3.   end finally
4.   end;
5.  

Barbarity, like the code below. Just a break for the case. You can write like that, but it's easy to get in the face for that. That's what would not fence in this and it is proposed to expand the syntax. The user needs to be provided with a convenient tool, and he himself decides what to use.

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

1. repeat
2.   case Condition of
3.     0:
4.       begin
5.         if SomeValue < 0 then break;
6.         Inc(SomeValue)
7.       end;
8.     else DoSomething;
9. until true;

[AccurateAlx]

The outer try-finally-end is not needed, because you catch all exceptions in except-section and the program runs normally after except-section.

I disagree with you, but if in the except end is written Raise Exception.Create (...)? Just the finally come in handy here.

[Martin_fr]

So what's the problem? If necessary, then use try finally in try except block, this is an extension of the language, not a replacement.

There are plenty of other requests for something that saves typing a few identifiers/keywords.

Of course there are also existing features that could be argued to do exactly that kind of savings. Maybe the difference is the amount of text they save. Maybe the difference is part of the below... It does not matter.

The "reason"(s) is/are simple. Some are:

1) With lots of ideas like this, you have to draw the line somewhere. (there isn't enough manpower to maintain everything)

2) The code/implementation in the compiler needs to be written. Or a patch needs to be vetted.

3) The code/implementation needs to be maintained. Every line in the compiler, may add extra work for whatever will be added in future.
3a) Don't assume it's dead simple to implement. Maybe it is, maybe not. Depends on how the code looks today. That existing code (into which to add) has undergone several decades of growing.

And that means, even if you provided a patch, someone has to add it, and has to take responsibility for maintenance. And if no one (of the core team) feels up for this... Then it wont happen.
And even if someone was willing to put the time into it, they would still respect the opinions of their fellow team members.

Conclusion:

- I don't know how this is judged from a "language design" point. Even if other languages do have it, that does not mean it is good, or good for Pascal.  But I don't know the answer here.
- Technical: I don't know the work it would cost to add it. But the maintenance risk will be there.
- And lastly: The willingness of the team to bear the cost vs their personal estimation of its benefit.

[Martin_fr]

Also, if it really is just a simple patch:

Well fork the project. Apply the patch locally, and commit it to a local git.
Then a regular "git pull --rebase" will keep the patch on top, and keep you up to date with the main project (every few years you may have to resolve a conflict, but should be easy enough).

[Zoran]

We have it already, but the actual keywords are "try try" and "end finally":

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

1.   try try
2.   except
3.   end finally
4.   end;
5.  

Barbarity, like the code below. Just a break for the case. You can write like that, but it's easy to get in the face for that. That's what would not fence in this and it is proposed to expand the syntax. The user needs to be provided with a convenient tool, and he himself decides what to use.

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

1. repeat
2.   case Condition of
3.     0:
4.       begin
5.         if SomeValue < 0 then break;
6.         Inc(SomeValue)
7.       end;
8.     else DoSomething;
9. until true;

I showed these "keywords" just for fun... 

Anyway, you can extend the language yourself, after all:

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

1. //somewhere near the top of the unit:
2. {$macro on}{$define _try:=try try}{$define _finally:=end finally}{$define _except:=except}{$define _end:=end}
3.  
4. // ...
5.  
6. // and this code works:
7. _try
8.     // ...
9. _except
10.     // ...
11. _finally
12.     // ...
13. _end;
14.  

[fabiopesaju]

I showed these "keywords" just for fun... 

Anyway, you can extend the language yourself, after all:

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

1. //somewhere near the top of the unit:
2. {$macro on}{$define _try:=try try}{$define _finally:=end finally}{$define _except:=except}{$define _end:=end}
3.  
4. // ...
5.  
6. // and this code works:
7. _try
8.     // ...
9. _except
10.     // ...
11. _finally
12.     // ...
13. _end;
14.  

 
 
 

[PascalDragon]

While agreeing that there's no justification for the change suggested, I'd note that IMO it would be desirable to allow "start" as an alternative to "try" in the try-finally-end syntax (i.e. in the same way that "otherwise" aliases "else" in case statements.

NO. We do not add keywords just for the sake of adding them, because someone thinks that would be a nice to have (and that is clearly what your suggestion is!). If we would implement exception and resource protection blocks from the start, then yes, but not when there is an existing syntax in the same language that's been around for decades.

And otherwise and else inside case-statements is a special case (pun not intended) due to the former coming from ISO Extended Pascal and the later from Turbo Pascal / Delphi.

It's syntactic sugar - because both try … finally … end and try … except … end already exist - and it does not add any signifcant benefit. Not to mention that there are use cases where the finally should come before the except and then others where it's the other way round.
TL;DR: There is no interest of the developers to add this.

So what's the problem? If necessary, then use try finally in try except block, this is an extension of the language, not a replacement.

This construct has been discussion ad absurdum both here and on the mailing lists. It was rejected time and time again by us devs and it will continue to be.

[MarkMLl]

While agreeing that there's no justification for the change suggested, I'd note that IMO it would be desirable to allow "start" as an alternative to "try" in the try-finally-end syntax (i.e. in the same way that "otherwise" aliases "else" in case statements.

NO. We do not add keywords just for the sake of adding them, because someone thinks that would be a nice to have (and that is clearly what your suggestion is!).

I did- and I want to emphasise this- say IMO, and while I anticipated that our opinions would differ I believe that I am entitled to mine.

Apart from that I believe that far too much has gone into the language which now challenges the complexity of Ada: and that was considered to be grossly overweight in its day by almost everyone.

IMO- and again, I believe I am entitled to hold an opinion- far more work should have gone into researching ways to generalise the core language, so that features which are today part of the compiler could be moved into a privileged library layer. That would hopefully allay your constant complaint that the language is too complex to add stuff to just to "scratch somebody's itch".

The above is intended as a statement of my opinion as to the state of the project, please do not take it as a personal affront.

MarkMLl