Making a plea :)

[Ryan J]

And yet it's one of the basic principles of the language Pascal, one of the core principles. To give that up would mean, why use Pascal at all?

Also your assumption is wrong: e.g. in the Linux kernel devs are required to do declaration first despite GCC allowing differently, because it improves maintainence. They'd definitely benefit from a "feature" that enforces declaration first.

I see Pascal as a C++ with more sane syntax but indeed the pre-declare variables are probably the only truly unique thing about the language. It was an old idea that makes sense from the perspective of an educator but I think doesn't hold up 100% in the real world. Just my opinion.

I really would like to hear a detailed expiation of why the Linux kernel has that requirement and what specific problems they had. This may have been an idea the creator had personally and imposed top down. If not I would expect new languages to have abandoned the declare anywhere variables but I've never heard a person complain about them except long time Pascal programers.

[Ryan J]

In that case I suspect that you haven't looked very hard- particularly when you consider what languages were available when Pascal was first implemented.

Those are ancient languages which are not widely adopted. The entire should we say "active" programming field making modern programs uses languages with inline variables. Am I wrong? What % of the programmers are using those languages would be a better question. Not even Delphi can be included in that list anymore.

FPC may be the most used language worldwide with pre-declared variables. I would not be surprised.

[MarkMLl]

Those are ancient languages which are not widely adopted. The entire should we say "active" programming field making modern programs uses languages with inline variables. Am I wrong? What % of the programmers are using those languages would be a better question. Not even Delphi can be included in that list anymore.

Yes, you're wrong. When Pascal came out, 99% of high-level language programmers were using ALGOL, COBOL, FORTRAN and the rest were using Lisp or Dartmouth BASIC.

MarkMLl

[MarkMLl]

Also your assumption is wrong: e.g. in the Linux kernel devs are required to do declaration first despite GCC allowing differently, because it improves maintainence. They'd definitely benefit from a "feature" that enforces declaration first.

And they're /required/- as a matter of style- to put constant expressions on the LHS of comparisons after somebody almost sneaked a backdoor into the kernel under Dave Miller's name.

But those mandated styles are basically due to the weakness of the C language, even after the amount of improvement it's undergone influenced ultimately by Wirth's ideas. It's /far/ better to have properly-checked syntax and semantics.

MarkMLl

[marcov]

I've never seen another language with a requirement to pre declare variables outside of the code.

That doesn't make it a good thing. It just means that there is a lot of mindless copying of basic syntax in the hope that such superficial similarities convinces managers to wrongly assume that saves on retraining.

[marcov]

First, I am definitely _not_ in favor of inline variables but, there is at least one case in which they enable a programmer to write cleaner and simpler code and that is when using an "on the fly"/temporary variable makes it possible to break a complex expression into 2 or more simple ones whose results exist only until the value of the complex expression is determined.

Actually assuming anything on the lifetime of the inline variables, is yet another feature layer on top of that. I assume that a first implementation would be syntax only, without any guarantees of intermediate stack layout. I.e. stack only created and destroyed at resp begin and end of procedures.

Anything else would be quite a formidable guarantee/change to make with own backends.

[Ryan J]

Those are ancient languages which are not widely adopted. The entire should we say "active" programming field making modern programs uses languages with inline variables. Am I wrong? What % of the programmers are using those languages would be a better question. Not even Delphi can be included in that list anymore.

Yes, you're wrong. When Pascal came out, 99% of high-level language programmers were using ALGOL, COBOL, FORTRAN and the rest were using Lisp or Dartmouth BASIC.

MarkMLl

It's 2024 not sure why you keep bringing up those languages. Go find the top 20 most used languages in 2024 and they all have declare anywhere syntax I'm sure. Not saying this is argument against Pascal just that it's lost the argument in the wider field.

[MarkMLl]

It's 2024 not sure why you keep bringing up those languages. Go find the top 20 most used languages in 2024 and they all have declare anywhere syntax I'm sure. Not saying this is argument against Pascal just that it's lost the argument in the wider field.

Yes, I agree. But saying "it's not popular any more" is not a sufficient argument to depart from its founding principles.

MarkMLl

[Khrys]

[...] e.g. in the Linux kernel devs are required to do declaration first despite GCC allowing differently, because it improves maintainence.

I don't disagree, however there's one thing that hasn't been addressed here yet - inline variable initializers can run code. The following excerpt is more verbose in Pascal because it's simply not possible to dereference pointer parameters, call functions etc. in a  var  block:

Code: C  [Select][+][-]

1. int hmm_range_fault(struct hmm_range *range)
2. {
3.         struct hmm_vma_walk hmm_vma_walk = {
4.                 .range = range,
5.                 .last = range->start,
6.         };
7.         struct mm_struct *mm = range->notifier->mm;
8.         int ret;
9.        
10.         /* [...] REST OF CODE REMOVED FOR BREVITY [...] */
11. }

This makes putting assignments on a separate line a necessity (instead of an option), and I'm sure most people would consider direct initialization to be more ergonomic.

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

1. function hmm_range_fault(range: phmm_range): cint; cdecl;
2. var
3.   hmm_vma_walk: thmm_vma_walk;
4.   mm: pmm_struct;
5.   ret: cint;
6. begin
7.   with hmm_vma_walk do begin
8.     range := range;
9.     last := range^.start;
10.   end;
11.   mm := range^.notifier^.mm;
12.  
13.   { [...] REST OF CODE REMOVED FOR BREVITY [...] }
14. end;

[Ryan J]

I want to update my list of things unique to Pascal outside of pre-declare variables.

1) The preference for words over symbols. Basically every popular language has curly brackets except Python (the worst syntax IMO).

2) You can't declare complex types in parameter lists. In other languages the parameter lists can be horrible to read because the language lets programmers be lazy and not write type names.

3) The module system with uses and neatly defined interface/implementation section. I still prefer this over other languages even though it has downsides of duplicate function definitions.

4) Classes can never contain methods with code mixed in with the definition like every other language I've used so you get neat ledgers that are easy to browse.

5) Anything else? Maybe non-zero based arrays with a range? There may be more.

[Ryan J]

That doesn't make it a good thing. It just means that there is a lot of mindless copying of basic syntax in the hope that such superficial similarities convinces managers to wrongly assume that saves on retraining.

Maybe. I'd like to see a comprehensive poll of programmers and if they struggle with dislike inline vars. My guess is no because new languages that have had decades of experience with C have not identified this one area as problematic. People have endless complains with C in 2024 but I never heard inline vars as one of them.

[Ryan J]

Code: C  [Select][+][-]

1. int hmm_range_fault(struct hmm_range *range)
2. {
3.         struct hmm_vma_walk hmm_vma_walk = {
4.                 .range = range,
5.                 .last = range->start,
6.         };
7.         struct mm_struct *mm = range->notifier->mm;
8.         int ret;
9.        
10.         /* [...] REST OF CODE REMOVED FOR BREVITY [...] */
11. }

What does that have to do with inline vars? Looks like a constructor would do that same thing. I don't see how inline vars change anything either way.

[MarkMLl]

1) The preference for words over symbols. Basically every popular language has curly brackets except Python (the worst syntax IMO).

Well, at least we agree about Python's syntax :-)

2) You can't declare complex types in parameter lists. In other languages the parameter lists can be horrible to read because the language lets programmers be lazy and not write type names.

That would be pointless, since the declaration would be local to the procedure and the type would be distinct from anything defined elsewhere.

3) The module system with uses and neatly defined interface/implementation section. I still prefer this over other languages even though it has downsides of duplicate function definitions.

I prefer the Modula-2 style with separate definition and implementation files, which apart from anything else avoids the legal problem of the declaration being in the public domain (as a statement of fact) but the implementation being proprietary. The Google/Oracle row over Java was sufficiently nasty, without introducing different explicit statements of ownership and license into the same file.

4) Classes can never contain methods with code mixed in with the definition like every other language I've used so you get neat ledgers that are easy to browse.

My response to (3) above applies.

5) Anything else? Maybe non-zero based arrays with a range? There may be more.

Yes, the fundamental problem: the language is far too big: bigger than PL/I and Ada which in their day were considered to be oversized.

MarkMLl

[Ryan J]

2) You can't declare complex types in parameter lists. In other languages the parameter lists can be horrible to read because the language lets programmers be lazy and not write type names.

That would be pointless, since the declaration would be local to the procedure and the type would be distinct from anything defined elsewhere.

The compiler can figure this out. This is from Swift. Notice the restorationHandler type. Pascal does have the very verbose array types in parameters and Swift is maybe easier to read honestly. [NSUserActivityRestoring] would be "array of NSUserActivityRestoring" which is a bit much.

func application(_ application: NSApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([NSUserActivityRestoring]) -> Void) -> Bool

[MarkMLl]

The compiler can figure this out. This is from Swift.

No. Don't care what Swift does: Pascal and its relatives defines the scope of types, like variables, to be determined by the scope of the syntax. And Wirth, when considering types, has leaned towards the position that types which are textually similar are still distinct. So there are some things which are really non-negotiable.

I'm not saying that I like all the decisions that Wirth made, but I've written quite enough about that (and the things that apparently drove him to those decisions) in the past.

MarkMLl