Why Pascal?

[Thaddy]

but note typed consts are typed. So although const necessarily  has a different meaning it is quite natural.

Typed? Natural? What makes it typed?
Not to mention that you can declare true constant's type explicitly, as well:

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

1. const
2.   N = Int64(123); // a true const
3.  

That is a constraint, not a type. A const is typeless, usually platform dependent as well. Only its value is guaranteed.
A const is evaluated by the compiler and can be substituted by a fixed value without storage. A typed const has an actual storage allocation.
Basics.... <means beyond grumpy! >

[ASBzone]

Way back when, I wanted to be a programmer...

I learned BASIC on a TRS-80, then on other home computers from TANDY, then on the C-64.
I also learned Assembler on the C-64.

In 1986, I ran into Pascal on a DEC PDP-11/44 at college -- it was awesome.
I started looking for Pascal everywhere.

Back on the PC, I got into BASIC again, and into dabbled briefly in Assembler again.  I did QuickBasic and AmigaBASIC (my favorite BASIC interpreter).
I dabbled in VisualBasic, but was not too impressed.

I started working as a hardware guy, not a software guy, and my career took off.    I still programmed, sporadically, as a hobby...   I loved TurboPascal.

Delphi came out, and I was in awe.  Loved it, loved it, loved it.

I also started learning C and C++.  Meh.   Nice languages, but nothing like Pascal for me (totally subjective sentiment).

Back in 2011, I found the need to write some utilities for systems management purposes, and after playing around with Visual C++, I came across FPC and Lazarus, and felt right at home.

It works for me.

If I had never run into Pascal, I would probably have gone on to master C++ and later C#, since I spend most of my time on Windows systems these days.

For me, Pascal just happened to suit my personality, and has been quite capable of doing all that I have needed.  (These days, I am mostly writing console utilities, but I have some additional software plans ahead.

[ASBzone]

And a very strict separation of declaration and implementation throughout the language, which makes it not only easier to read but also less prone to errors than C like languages that allow e.g. variable declarations within a code block... even on the fly.... which is silly although it "saves time"..<think!  >.

I was *just* having that discussion with my teenage son yesterday, as he was lamenting the structure of Pascal, in favor of the *flexibility* of Python.

[engkin]

Since this thread is in a forum for "Pascal" it will be more like glorifying Pascal as a programming language.

I also started learning C and C++.  Meh.   Nice languages, but nothing like Pascal for me (totally subjective sentiment).

Thank you for being objective here.

I would like to remind Pascal lovers of the following cryptic list of local and global compiler directives:

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

1. {$A}
2. {$B}
3. {$C}
4. {$D}
5. {$E}
6. {$F}
7. {$G}
8. {$H}
9. {$I}
10. {$J}
11. {$L}
12. {$M}
13. {$N}
14. {$O}
15. {$Q}
16. {$R}
17. {$S}
18. {$T}
19. {$V}
20. {$W}
21. {$X}
22. {$Y}
23. {$Z}
24.  

You should not use any of them, if you really care about your code being easy to read, you know. If you see a member using {$H+} in their code and claims Pascal is easy to read, ask them to use {$LONGSTRINGS ON} instead, just to be consistent. You can't hate count++ and use {$H+}.

{$WRITEABLECONST} is just another funny Pascal readability issue. I don't know what it does to prevent errors/mistakes, but it almost proves that this is a missing part in the language itself, replaced with an abuse of a compiler directive.

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

1. {$push}{$J+}
2. ...
3. {$pop}

[Thaddy]

Compiler directives are not necessarily part of the Pascal language. Strictly speaking they aren't.
But cryptic syntax is always possible:

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

1. begin write(^M^J^G);end.

Now, how many of you remember what that does.?

[engkin]

Compiler directives are not necessarily part of the Pascal language. Strictly speaking they aren't.

Yes, sure. They are not part of the language. Still practically the language can not be used without them. 

But cryptic syntax is always possible:

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

1. begin write(^M^J^G);end.

Now, how many of you remember what that does.?

Equivalent to #13#10#7.

the caret character (^) can be used in combination with a letter to specify a character with ASCII value less than 27. Thus ^G equals #7 - G is the seventh letter in the alphabet. The compiler is rather sloppy about the characters it allows after the caret, but in general one should assume only letters.

[Thaddy]

Equivalent to #13#10#7.

Equivalent to mechanical typewriter (return + bell).
There's a difference, though. Technically the ^M syntax is - the only - true Pascal escape syntax whereas #13 syntax is simply byte representation of a char misused for escaping. (yes, I know, it has the same result but semantically that is the case  )

[metis]

@Handoko

Have you read the link? Typed constant is not the constant that you thought.

Yes, it is (sorry).
I only have Internet-Access at my work place, where I cannot read all Posts, that came in the Meantime and then answer accordingly.
So, I simply didn't see the Citation written in green and the Link below.

@Handoko + Pascal + Thaddy
Though I use typed Contants quite often, I never did within Routines.
From now on, I will - Thanks for Your Hints.


@Zoran

However, the syntax is quite unfortunate.

In my Opinion, as well, it's quite misleading to name something a "Constant", that is variable,
even if it can be seen as "constant over calls" as Thaddy mentioned. (I also fell into that "Trap".)

Perhaps we should call these global variables with local scope

Or simply "static variables".

I'd do it this way:

It depends on how You define an "exact block" - I wouldn't call a Unit or the Program itself an "exact block".

@lainz

He means in each scope. With your code you are creating a variable for all function scope, ...

I actually meant in each scope in the Sense of being available anytime and anywhere in the Program.
You pointed out another Issue.

 

[howardpc]

@Zoran

However, the syntax is quite unfortunate.

In my Opinion, as well, it's quite misleading to name something a "Constant", that is variable,
even if it can be seen as "constant over calls" as Thaddy mentioned. (I also fell into that "Trap".)

Perhaps we should call these global variables with local scope

Or simply "static variables".

AFAIK the "typed constant" description is nomenclature inherited from TP / early-Delphi times, we can't blame the FPC developers for that.
Personally I prefer to call them "initialised variables". It is one of many areas where a multiplicity of overlapping terms is not particularly helpful, and probably confusing to newcomers. However, we cannot undo our history, or insist that others use some preferred or standard name.
They used to be stored always in the data segment, not as part of the heap. Where does the compiler keep them these days?

[Zoran]

AFAIK the "typed constant" description is nomenclature inherited from TP / early-Delphi times, we can't blame the FPC developers for that.

Yes, the unfortunate naming is Borland's fault.

Personally I prefer to call them "initialised variables".

But now whe have initialized variables which behave differently from typed consts, see: https://www.freepascal.org/docs-html/current/ref/refse24.html

Unlike typed constants, local initialized varibles are initialized on each routine call (so, I guess they are on the stack, and typed constants are in global memory area).
So, I wouldn't call typed constants "initialized variables", as "initialized variables" are something else.

By the way, we can also notice that global initialized variables and global typed constants (with {$J+}) actually do behave quite same, they are probably implemented same in compiler.

[metis]

@howardpc

we can't blame the FPC developers for that.

I didn't want to blame the FPC-Developers, but everything can be improved.
 

[Thaddy]

AFAIK the "typed constant" description is nomenclature inherited from TP / early-Delphi times, we can't blame the FPC developers for that.

Yes, the unfortunate naming is Borland's fault.

No it is is not. Typed constants are not even unique to Pascal.
To mention a few: several COBOL dialects, ADA and C++.
For somebody that actually read the theory it is perfectly valid and logical naming. Typed vs Literal should be enough to understand it..
https://en.wikipedia.org/wiki/Constant_(computer_programming)

[marcov]

Having true structured consts is important in embedded applications where it is backed by flash or placed in a non writable code segment rather than data.

[Zoran]

AFAIK the "typed constant" description is nomenclature inherited from TP / early-Delphi times, we can't blame the FPC developers for that.

Yes, the unfortunate naming is Borland's fault.

No it is is not. Typed constants are not even unique to Pascal.
To mention a few: several COBOL dialects, ADA and C++.
For somebody that actually read the theory it is perfectly valid and logical naming. Typed vs Literal should be enough to understand it..
https://en.wikipedia.org/wiki/Constant_(computer_programming)

No. I have no idea about ADA and COBOL, but the constants in C++ are constant, being typed is completely irrelevant, when declared as const, once initialized, they are not writeable.

[Thaddy]

In C++ - depending on compiler settings - it is possible to change the value of a named constant within its scope. That is basically the same as Pascal.
The big difference between const and named/typed const is memory allocation. Named consts and typed consts have an address....