Re: language improvement suggestions (the spin off)

[Thaddy]

The last time I spoke to a COBOL programmer was in the early 90th.

That's quite a story - thanks for sharing.

Well, we have discussions here    and I get approached several times a year to pick up some COBOL maintenance.
It is still widely used and tariffs come with a premium of 50% over a normal hourly rate for a senior programmer.
Alas, I can not accept those anymore for health reasons (nothing too serious, but restrictive), but I have a network to help the recruiters out.
To me it is still lucrative business: I invariably am on their Christmas box list and not on the cheap list.
They do not have much imagination, though: it is always a side of smoked salmon and a bottle of bubbles, usually from some French widow. (Ok, will do.. )

[PascalDragon]

Sorry, guys. I'm just a noob but may I suggest we should follow the freebasic's way of creating new object pascal dialects? Please keep the current objfpc dialect as is and testing the new features with {$mode objfpc-next} ? We should add a switch to the compiler, e.g. fpc -lang objfpc-next ? I know someday objfpc-next have to be merge with objfpc but I don't think it's the way it should be. I prefer the objective c way, we may rename our current objfpc dialect with objfpc1 and the new dialect should be objfpc2. It's the best way I could imagine.

First of new language features are usually added together with a modeswitch that can be used independently of the mode. In some modes a new modeswitch might be enabled by default (mainly Delphi compatible features in mode Delphi), but in most they aren't.
You can already set the mode on the command line using the -M parameter: -Mdelphi or -Mobjfpc. This also works with modeswitches however they are reset once a {$mode XXX} has been read.
And I already had the idea to introduce a derivative of the ObjFPC mode that is less conservative in its approach.

OK. I read the first post. I don't understand much as you professionals but may I have my own opinion? I think readability is not really a problem for me but I prefer simplicity. At the first glance I think freebasic is an easier to read version of C, I even could use standard C libraries by #include once "crt/stdio.bi" but after some attempts I failed and revert back to plain C. A more wordy language with more shortcuts could make things easier to read and understand but more inconvenient to write. We should keep the balance between readability and simplicity. People could have his/her own adventures with his/her own dialects, e.g. {$mode objfpc-440x} I think the compiler's devs would be pleasant to merge these dialects. The dialects will prove themselves by the number of users of it. I know, something is clearly good, clearly superior or someone will not clearly good, clearly superior with others. After all, we're clearly very different person 

We are very reluctant to add new features if there isn't any real gain even if users provide patches. Things like constants for generic types are good ideas while others like the multiline strings are more controversial. Also we won't integrate experimental modes into the trunk compiler.

Now I tried to use inc() for properties, doesn't work. So what are we waiting for?

It does not work by design. And the reason is the same regarding side effects. C-style operators used to work for properties as well, but using them resulted in problems which is why they were disabled. Same would be true for Inc and friends.

Besides the technical aspects, I understand that adding features is very difficult. To find an agreement in the community perhaps is more difficult than the Brexit-negotiations in the British parliament.
So sticking to Delphi syntax makes the development and the program environment more stable, the language won't drift away.

It's not about sticking to Delphi syntax. We do add language extensions that Delphi does not support, but we are very reluctant with that as we also keep in mind the spirit of the language (which is why there is a 5 year moratorium on inline variables) and the feature needs to provide significant gain instead of simply being syntactic sugar.

Alternative:

Introduce TTuple

And

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

1. case TTuple(...) of
2.   TTuple(...) : ;
3.   TTuple(...) : ;
4.   TTuple(...) : ;
5. end;
6.  

It is different:
- the labels must be constants.
- it only has equality test (no range in ...)
- It would not have the names, in front of each value as I would like....

But it be a table.
It only evals once.
It enforces the column count.

It might be useful for other stuff. So the "case TTuple" would be a side effect, and the argument would come from other parts of the feature.
 
I have currently no particular opinion if TTuple should actually be added

See also this feature request together with a patch.

[winni]

Forgetting free or freeAndNil leaves after terminating an unfreed memory block.

To detect those blocks use the unit heaptrc.

It is described here:

https://wiki.freepascal.org/heaptrc

And don't mention FreeAndNil too often. Some people think that it's bad style and evil!

Winni

[guest64953]

Forgetting free or freeAndNil leaves after terminating an unfreed memory block.

To detect those blocks use the unit heaptrc.

It is described here:

https://wiki.freepascal.org/heaptrc

And don't mention FreeAndNil too often. Some people think that it's bad style and evil!

Winni

Sorry I deleted my post because I think I should post a new thread so it make your post to be answer to nowhere 

This heaptrc is useful. I will check it 

[Martin_fr]

Simply: no.  There is nothing in a chain of if/then/else statements that makes a tabular structure readily identifiable.  Such a chain could be anything.

I might have just found a clue, to why my perception is so different.

I came across some code
  function DoContinueStepping: Boolean;
line 7000, gdbmidebugger.pas

At the moment its a mix of nested "if" and "case". After refactor, it might look like

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

1. if RunMode =abc then begin
2.   case FStoppedReason of
3.      // enum
4.   end;
5. end
6. else begin
7.   case FStoppedReason of
8.      // enum
9.   end;
10. end;

And yes, that could perfectly well be expressed in a table / evaluate.
But I would not do that, even if it was available. Simply because to me, the logical flow is a decision tree. So I actually want to represent it as such. And that means to write it as nested code.

If hypothetically both (or all) conditions would have same priority. So if from a logical/design point the order in which they are checked would not matter, then a table may represent that idea better.
But the above reminds me of another factor.
If I put all of this into a table, then all conditions are in a single statement. Forcing me to read them all at once.
In the nested scenario, I split the condition into 2 (or more) levels. That means reading the "if" I have to deal with a lot less info. And reading each "case", there is also less info. Presenting the information in smaller chunks IMHO can also help reading the code.

My guess is that I am simply to used to splitting up decisions into smaller chunks (generally I am a fan of modularization / not that I always do as I preach, but...) => and that explains why I have a big aversion towards a construct that aims to do the opposite.

That said, there are other flaws with the control flow in the mentioned code. But the are outside the scope of the if/case/evaluate. And not influenced by either of them.

[440bx]

Before anything, I want to make it very clear this post is NOT about the "evaluate" statement (I'm done with that!), it is simply some thoughts about how to improve the Pascal language.

One of the interesting, not to mention humorous, posts in this thread is:

I can see the release manifest for that release

- NOW WITH NEW COBOL FEATURES ! 

That will win us the hearts of new programmers. 

Given that COBOL is a language that isn't particularly held in high regard by a significant percentage of programmers, the point made in the above post is quite likely to be true.

Now, presuming for a moment that, there is at least some desire among Pascal lovers (and, in spite of what some may think, I am among them) to win the hearts of new (and existing) programmers, it is reasonable to give some thought to how this might be accomplished.

One thing that should not be a surprise to anyone is that, among compiled languages, C is at the top of the heap and has been there for a long time.  In the last few years, Java usually occupies the first place but it is not compiled (thus out of consideration for the time being.)

Given that situation, the areas Pascal could draw mindshare from are, new programmers and existing C programmers.  One of the nice things is that, in the case of C programmers, they could potentially redirect their interest towards a language that is everything that C is and then some while being simpler and cleaner.

Pascal is definitely simpler and cleaner.  That doesn't have to be achieved, it is simpler and cleaner by design (thank you Mr. Wirth) but, porting C to Pascal can often be a lot more work than meets the eye.

I believe that _one_ of the things that has the potential of winning the hearts of C programmers is to have an alternative (hopefully Pascal) that offers just about every one of the C language features, in such a way that, there is more often than not, a one to one relationship between a line of C to a line of Pascal.  I am fully aware that the C preprocessor will most likely preclude accomplishing a one to one relationship but, it is possible to get very, very close.

Ultimately, the inevitable point is, Pascal/Delphi is currently a language in _decline_, we may not like it but, that's the reality and, following in the footsteps of Delphi is rather unlikely to result in gaining programmer mindshare, on the contrary, everything so far points to the result being a slow and long path to becoming a zombie language.

I believe, maybe I'm deluded, that it is possible to dislodge C as the "premier" programming language but, in order to accomplish that, we have to look at the development of Pascal in a much different way.  That seems to be the "insurmountable" mountain so far.

Admittedly the above is very vague, so I'll give an example based on something that has been mentioned in this thread: inline variables.

Like most everything, inline variables have their pros and cons.  Without going into too much detail, one of their very significant cons is that they completely violate the structural essence of Pascal (and good/structured programming too).  There is a solution that is pure Pascal, fully structured programming compliant to implement inline variables which is, define a scope to house the variables, just like function and procedure do.  For instance (this from a previous thread):

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

1. SomeProc(parameters : types, ...);
2. const
3.   aconst : 123;
4. type
5.   sometype = 1..10;
6. var
7.   whatever : sometype;
8. begin
9.   statement;
10.   statement;
11.   ...
12.   scope step1;
13.   { any definitions/declarations within a scope are local to the scope }
14.     type
15.       scopetype = sometype;
16.     const
17.       scopeconst = 3;
18.     var
19.       scopevar : integer;
20.   begin
21.     statement;
22.     statement;
23.  
24.     if somecondition then break; { breaks out of the scope - not the function/procedure - just like in a loop }
25.  
26.     statement;
27.     statement;
28.   end;
29.  
30.   scope step2;
31.   begin
32.    statement;
33.    statement;
34.    ...
35.   end;
36. end;
37.  

by being able to define a scope, not only are "inline variables" possible, type and const declarations are also possible (if needed of course) and, the scope (note: this is just a conceptual example, meaning if a better syntax is possible, suggest away) is essentially the same thing as a nested function/procedure (which Pascal already does) but simply inline (and not necessarily requiring a stack frame) instead of declared at the top. 

The point of the example is NOT to request a new feature but, to show that just extending current Pascal constructs (function/procedure), it is possible to implement some extremely useful features in a very simple and very clear way.

Totally related to the above even though it is not immediately obvious is

My guess is that I am simply to used to splitting up decisions into smaller chunks (generally I am a fan of modularization / not that I always do as I preach, but...) => and that explains why I have a big aversion towards a construct that aims to do the opposite.

When programming in one language or another, the programmer gets used to designing code based on what the language offers.  That's a critical problem.  It's the "when all you got is a hammer, everything looks like a nail" problem.  Consciously and unconsciously, a programmer designs a program using the tools the language offers.  Obviously, that's the only avenue that can lead to the successful implementation of a program using that language but, when a programmer is conversant in mostly or uniquely one language, that results in limiting the number of ways he/she can implement a design.  Unfortunately, this permeates in the design of computer languages and their evolution.


@Martin

I'm very pleased you're still thinking about the logical structures represented by "evaluate" and "if/then/else".

[del]

Object Pascal is already head and shoulders above C, by virtue of the fact that it's object oriented. C++ is the true rival, and Object Pascal lags cuz it doesn't have scope-based memory management, IMHO. But I can live with that, I just run heaptrc. 

[Thaddy]

it doesn't have scope-based memory management, IMHO. But I can live with that, I just run heaptrc. 

It does. (reference counted) Interfaces and all but the shortstring string types. and it works perfectly OK.

[Martin_fr]

I'm very pleased you're still thinking about the logical structures represented by "evaluate" and "if/then/else".

Something to think about (not necessarily to argue):
There is also a different between "else if" and "elseif". They may do the same thing, but they express a different structure.

Yet, would we need them both? Especially, when looking at languages that have both, we can see that they are hardly used to express that difference?

When programming in one language or another, the programmer gets used to designing code based on what the language offers.

Just to be clear, I have been exposed to my fair share....

Your statement would then IMHO apply, that counting the occurrence, where a tool was used (without looking at any further detail) does not make any statement about the quality of that tool.

[del]

it doesn't have scope-based memory management, IMHO. But I can live with that, I just run heaptrc. 

It does. (reference counted) Interfaces and all but the shortstring string types. and it works perfectly OK.

OK, my friend - that's new territory for me so I'll have to check that out. 

[winni]

I can see the release manifest for that release

- NOW WITH NEW COBOL FEATURES ! 

That will win us the hearts of new programmers. 

Hi marcov! Look at the attachment!

Made with BGRABitmap 10.6

[BeniBela]

A more flexible improvement would be computed gotos. Then you can create your own evaluate table as array, and jump to the case with goto.

For example, if there are four cases, depending on two boolean variables, you could do:

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

1. var a, b: boolean;
2. label AB, notAB, AnotB, notAnotB;
3. var map: array[boolean, boolean] of pointer = ((@notAnotB, @notAB),
4.                                                (@AnotB, @AB));
5. begin
6.   goto map[a,b];
7.  
8.   AB: ;
9.      exit;
10.   notAB:;
11.      exit;
12.   AnotB: ;
13.      exit;
14.   notAnotB:;
15.      exit;
16. end;
17.  

The labels and the array already compile fine, only the goto line is invalid syntax

[440bx]

Object Pascal is already head and shoulders above C

No, it is not.  A programmer who plans on writing an operating system is rather unlikely to choose Pascal for it.  Additionally, if Pascal was "head and shoulders" above C, it is very doubtful that would lead to C having in excess of 10 times more programmer mindshare than Pascal.   

From a design standpoint, I consider Pascal to be heads and shoulders above C but, when it comes to power and flexibility, C is still heads and shoulders above Pascal.

by virtue of the fact that it's object oriented. C++ is the true rival

C++ doesn't even have half the programmer's mindshare of C. C++'s Object orientation has not unseated C as the preferred compiled language and, the historical trend shows that, unless something drastic happens such as MS ramming it down the programmer's throats, which it has done on more than one occasion, that is unlikely to change.

When programming in one language or another, the programmer gets used to designing code based on what the language offers.

Just to be clear, I have been exposed to my fair share....

Your statement would then IMHO apply, that counting the occurrence, where a tool was used (without looking at any further detail) does not make any statement about the quality of that tool.

I have no doubts you've been exposed to your fair share of programming languages.  Obviously, I can only speak for myself but, I've lost count of the number of programming languages that I've used for a short (a year or less) time or simply played with to find out what they were all about (C# comes to mind.) I think a lot, if not most, programmers have traveled that road.

But, when it comes to genuine, _true_ expertise in a language, which I define as seeing the resulting assembly code and execution as you type the source, then my personal count drops to about five (5).  The reason that's important is because it really takes a reasonably high level of experience and expertise to fully see how specific constructs in a language result in simpler, better and more maintainable code.   A decent idea can be obtained from a lower level of expertise but, often, that lower level of expertise and experience results in some subtle but important aspects of one or more constructs to be missed or underappreciated.

That's what causes the "when all you've got is a hammer, everything looks like a nail." 

To use the inline variables as an example again.  It is likely totally evident to a compiler writer how undesirable in every way that feature is as the Delphi developers plan to incorporate it into Pascal but, localizing the declaration of variables as well as types and constants, is a very desirable feature (that's one of the nice features of functions and procedures: local variables.)

The point here is that, there are really great features in some languages.  Some of them are not implemented quite "correctly", inline variables being a good example of that, even in C, but the idea has a lot of merit and _can_ be implemented correctly and elegantly.   I believe that is one thing that should influence the development of Pascal.  Get the good ideas and put Niklaus Wirth's touch of correctness and elegance on them.  Shamelessly steal the good stuff from other languages and implement it the right way.  The Japanese proved that works!   (most dangerous thing to proprietary technology is a Japanese with a camera... Techzilla!)

A more flexible improvement would be computed gotos. Then you can create your own evaluate table as array, and jump to the case with goto.

For example, if there are four cases, depending on two boolean variables, you could do:

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

1. var a, b: boolean;
2. label AB, notAB, AnotB, notAnotB;
3. var map: array[boolean, boolean] of pointer = ((@notAnotB, @notAB),
4.                                                (@AnotB, @AB));
5. begin
6.   goto map[a,b];
7.  
8.   AB: ;
9.      exit;
10.   notAB:;
11.      exit;
12.   AnotB: ;
13.      exit;
14.   notAnotB:;
15.      exit;
16. end;
17.  

But there is a very significant downside to that construction.  It's easy to get the order of the pointers in the array wrong and, the compiler cannot detect that. Also, the fact that the pointer is pointing to the wrong option isn't necessarily always obvious.  Additionally, it splits the actions away from the conditions, now the burden is on the programmer to "assemble" in his/her mind what pointer goes with what condition or set of conditions, the compiler should do that, not the programmer.  Programmers have enough to worry about.

[del]

Object Pascal is already head and shoulders above C

No, it is not.  A programmer who plans on writing an operating system is rather unlikely to choose Pascal for it.  Additionally, if Pascal was "head and shoulders" above C, it is very doubtful that would lead to C having in excess of 10 times more programmer mindshare than Pascal.   

From a design standpoint, I consider Pascal to be heads and shoulders above C but, when it comes to power and flexibility, C is still heads and shoulders above Pascal.

by virtue of the fact that it's object oriented. C++ is the true rival

C++ doesn't even have half the programmer's mindshare of C. C++'s Object orientation has not unseated C as the preferred compiled language and, the historical trend shows that, unless something drastic happens such as MS ramming it down the programmer's throats, which it has done on more than one occasion, that is unlikely to change.

Awright - first thing Monday morning I'll ask around: "Hey guys, done an operating system lately?". "Nah - we just use the store bought ones".

[Thaddy]

Awright - first thing Monday morning I'll ask around: "Hey guys, done an operating system lately?". "Nah - we just use the store bought ones".

Don't forget to mention https://en.wikipedia.org/wiki/Apple_Lisa  and its successor Classic Mac OS.