NIL vs. Assign: when to use - or: what are the differences ?

[paule32]

I know the story so:

- N. Wirth teach students programming.
- to "not" fall in pitpoints (the students) he invent Pascal as structured Language with pre-defined consts/vars/proc/func...
- to load big Computer Applications on smaller Computer's other than (mainframe)Servers.
- for compatibility he invent the P-Code (a binary pseudo Code - like the modern byte code which is used as virtual machine code that can be transformed into CPU code at load time)
- and he used Pascal to create Applications like LaTeX, to layout his books and articles.
- the rest is obligartoical - because it covers programming styles and compiler construction...

[MarkMLl]

in a hurry, for political reasons : source please.

What political reasons ?

Together with almost half of the ALGOL-68 committee he resigned when his proposal was dismissed. Part of the reason was that he couldn't stand up to McCarthy, who was a much more senior academic and until recently had been his boss at Stanford. https://www.tomandmaria.com/Tom/Writing/DijkstrasCrisis_LeidenDRAFT.pdf

He hurriedly reworked ALGOL-W to incorporate ideas largely from Tony Hoare, breaking the declarations enough for it to be incompatible with ALGOL but not able to do very much with the syntax since ALGOL-W used recursive ascent (rather than descent) which is a bitch to maintain. Some things were lost, notably the conditional expression (as distinct from statement).

He started in April '68, and believed that he needed to get something usable- at least to the extent that the Autumn's intake of postgrads could help him- before the ALGOL-68 report was published. In practice, the report was flawed and needed to be reworked and if he'd know that in advance he might have done a better job.

He fairly rapidly reworked the compiler to use recursive descent, which resulted in the first of the P-series.

The original description of the language was published in 70 or 71 https://www.research-collection.ethz.ch/bitstream/20.500.11850/68712/1/eth-3290-01.pdf . The first edition of the Pascal User Manual was in 1973 https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68910/eth-3059-01.pdf . The second edition (with kathleeen Jensen) was in the following year http://pascal.hansotten.com/uploads/books/Pascal_User_Manual_and_Report_Second_Edition.pdf .

MarkMLl

[dseligo]

Discarded or not, it is necessary to distinguish between a function call and a function reference.  That's what the presence of parentheses _should_ do.

You have '@' for that distinction. And it's even better because it is much more clear of programmers intentions and it is used in fewer occasion than calling a function/procedure.

C is a syntactic atrocity yet, they got it right.  That's why in C there is a "return" statement, instead of this bad idea of assigning to a function identifier.  It's one of those ideas that looked good at the time that turned out to be a really bad one (which the pseudo-variable "result" mitigates to some extent.)

You can also use Exit(your_result);

[440bx]

You have '@' for that distinction. And it's even better because it is much more clear of programmers intentions and it is used in fewer occasion than calling a function/procedure.

two things apply to that remark.  1.) in a correct design it is unnecessary to use the address of operator to obtain the address of code since the name of the function/procedure identifies that location.  2.) since it is genuinely unnecessary to use the address of operator for that purpose, using it for that purpose is NOT problem free.  It is simply an indication of a flaw in the design of the language.  The same way that assigning a value to a function using the function identifier is a flaw because the function identifier is by definition the address of the function's code, therefore it is not an lvalue (or at least, should not be treated as one.)

You can also use Exit(your_result);

where do you think that idea came from ?... yes, it's just C's "return".  Unfortunately, in Pascal it doesn't do anything to solve the problem of distinguishing between a call and a reference.  Actually, the ability of referencing a function's result by using the "result" identifier is an improvement over that because it allows to use the function's result in the body of the function without exiting it, something that "exit(...)" doesn't provide.

A reasonable argument could be made that "exit" should not take a parameter.  That would make its usage the same whether it is used in a procedure or a function which is not currently the case since when used in a procedure, specifying a parameter for it, is semantically incorrect.

[MarkMLl]

You have '@' for that distinction. And it's even better because it is much more clear of programmers intentions and it is used in fewer occasion than calling a function/procedure.

two things apply to that remark.  1.) in a correct design it is unnecessary to use the address of operator to obtain the address of code since the name of the function/procedure identifies that location.  2.) since it is genuinely unnecessary to use the address of operator for that purpose, using it for that purpose is NOT problem free.  It is simply an indication of a flaw in the design of the language.  The same way that assigning a value to a function using the function identifier is a flaw because the function identifier is by definition the address of the function's code, therefore it is not an lvalue (or at least, should not be treated as one.)

In any event, this is something that PascalDragon commented on earlier in the thread: if I'm interpreting him correctly parentheses are desirable to avoid ambiguity.

You can also use Exit(your_result);

where do you think that idea came from ?... yes, it's just C's "return".  Unfortunately, in Pascal it doesn't do anything to solve the problem of distinguishing between a call and a reference.  Actually, the ability of referencing a function's result by using the "result" identifier is an improvement over that because it allows to use the function's result in the body of the function without exiting it, something that "exit(...)" doesn't provide.

A reasonable argument could be made that "exit" should not take a parameter.  That would make its usage the same whether it is used in a procedure or a function which is not currently the case since when used in a procedure, specifying a parameter for it, is semantically incorrect.

I'm unhappy with exit(), since it dolls up a control structure as a function or procedure but departs from the normal semantics (stack same on entry and exit etc.).

MarkMLl

[MarkMLl]

I know the story so:

- N. Wirth teach students programming.

After completing his doctorate at Berkeley he moved to Stanford where he was engaged in research and supervision. I don't know how much of a teaching load he had.

- to "not" fall in pitpoints (the students) he invent Pascal as structured Language with pre-defined consts/vars/proc/func...

No. Pascal was a continuation of his involvement with Euler (his doctoral project), PL/360, ALGOL-W and ALGOL-68. The fact that it can be viewed as attempting to instill good practice is secondary, since that was a major theme of the entire family of ALGOL languages.

- to load big Computer Applications on smaller Computer's other than (mainframe)Servers.

No. In the circles in which Wirth moved mainframe access was taken for granted; at Berkeley he'd used a Bendix, Stanford had IBM and Burroughs, and after moving back to Europe he used a CDC. The fact that Pascal, particularly if it used a single-pass compiler, was well-fitted to small computers was fortuitous.

- for compatibility he invent the P-Code (a binary pseudo Code - like the modern byte code which is used as virtual machine code that can be transformed into CPU code at load time)

Several of his early languages used some form of intermediate representation (with the notable exception of PL/360). However the P-series of compilers came along slightly later, after his transition from recursive ascent to recursive descent.

- and he used Pascal to create Applications like LaTeX, to layout his books and articles.

No, LaTeX was Knuth (one of Wirth's colleagues at Stanford, and among other things a consultant to Burroughs). It's since been converted to C etc., I don't think the current version has any Pascal remnants.

- the rest is obligartoical - because it covers programming styles and compiler construction...

Whatever that means ;-/

MarkMLl

[PascalDragon]

I something in my mind ... that I have read "noreturn" in the sources and documentation of FPC.
It could be like the "noexcept" keyword in C++ for methods that throws silent exceptions.
But I am not sure.
So, noreturn could be a CLOS Lambda methode that you can overgive arguments, but no return like:

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

1. function foo(sum: procedure test(argA: Integer; argB: Integer) begin
2. sum := argA + ArgB;
3. end): String; noexcept;
4. begin
5.   try
6.     result := IntToStr(sum);
7.   except  // 1 div 0
8.     ShowMessage('Error');  // this will no display, because: noexcept
9.   end;
10. end;
11.  

This would require marking/adjusting huge parts of the RTL accordingly to work correctly, especially as many core routines are capable of throwing exceptions.

[AlexTP]

https://wiki.freepascal.org/Exceptions
Guys, can you please add the info about 'noexcept' to this wiki page? (Seems the most suitable one). I tried search for 'freepascal noexcept keyword' and did not find FPC pages, only that.

[PascalDragon]

https://wiki.freepascal.org/Exceptions
Guys, can you please add the info about 'noexcept' to this wiki page? (Seems the most suitable one). I tried search for 'freepascal noexcept keyword' and did not find FPC pages, only that.

You did notice that this noexcept was merly a suggestion by paule32? So there is nothing to document.

[Zoran]

I something in my mind ... that I have read "noreturn" in the sources and documentation of FPC.
It could be like the "noexcept" keyword in C++ for methods that throws silent exceptions.
But I am not sure.
So, noreturn could be a CLOS Lambda methode that you can overgive arguments, but no return like:

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

1. function foo(sum: procedure test(argA: Integer; argB: Integer) begin
2. sum := argA + ArgB;
3. end): String; noexcept;
4. begin
5.   try
6.     result := IntToStr(sum);
7.   except  // 1 div 0
8.     ShowMessage('Error');  // this will no display, because: noexcept
9.   end;
10. end;
11.  

I totally don't understand this. 

[440bx]

I totally don't understand this. 

and you are not the only one.

I don't know what "noreturn" has to do with exceptions.  "noreturn" simply tells the compiler that the function/procedure does _not_ return to the caller.

This is documented at: https://www.freepascal.org/docs-html/current/ref/refsu84.html

That information could also be important for a programmer.  For instance, some programs have an "end procedure" that takes care of releasing all the resources the program acquired during its execution and then terminate gracefully.  Some error handlers, such as those for critical errors may also not return.  The important thing is that exceptions have nothing to do with the programmer's decision to not return from a function or procedure.
 
 

[paule32]

Hello from Thuringa - Eisenach
- there is the Eastern fiest where the Winter bunked from Miss Sun na...

- so I have lay out an Eastern Egg with my last Article..
- my Indention goes to this Article:
https://forum.lazarus.freepascal.org/index.php/topic,70531.msg550186.html#msg550186

And I was not thinking that FPC has Features like "noexcept".
I am simply put C++ against FPC.

Because I saw Code from "Fibonacci" that supports Lambda Functions.

And this was the Start of my Concern's and missunderstand FPC.
I write this to the Article, too. But nobody seems to be noticed it - it was only a stuckle in Cofe brew.

However, I don't remember me on the full Source Code but it had the Structure like the JavaScript JQuery Notation:

function( arg1: function(=> {
  // function Code there
}));

or:
------
function sum(arg1, function(arg2, arg3 => {
  arg1 = arg2 + arg3;
}));

which can be overload with:

function sum(arg1, arg2) {
  return (arg1 + arg2);
}

so the next thing I was thinking on was:

function sum(arg1, procedure(arg2, arg3) begin
  // inner scope
end; noexcept;
  // sum / outer scope
end:

and then I was thinking on "noreturn" and "noexcept" from C++
which in this case could be the calculus:  1 divided by 0 - which is not allowed, and give a UB.

[Khrys]

So, noreturn could be a CLOS Lambda methode that you can overgive arguments, but no return like:

What do you mean by CLOS? Closure? Common Lisp Object System? (BTW "overgive" does not mean "übergeben" - it's "zu viel geben" or rarely even "aufgeben")

I am simply put C++ against FPC.

Comparing C++ to Pascal, you mean?

But nobody seems to be noticed it - it was only a stuckle in Cofe brew.

What...?

which in this case could be the calculus:  1 divided by 0 - which is not allowed, and give a UB.

"Undefined behavio(u)r" has a very specific meaning, and division by zero most certainly isn't UB; in C++ your program would just terminate in this case.


I'm intrigued, but can't quite decipher what you're trying to say.     Könntest du das bitte auf Deutsch wiederholen?

[paule32]

Hallo,

Bitte vergebt mir mein Englisch - es ist schlecht, ja ich weiß - es ist nicht meine Hauptsprache und Englisch kenne ich nur von der Schule her, nicht jedoch als Expert mit englisch sprachlichen Potential.

Mit CLOS meinte ich Closure, was ich in Verbindung mit LISP her kenne, und auch meine bei JavaScript mal gelesen zu Haben.
Bei diesen Sprachen kann man Lambda-Funktionen verwenden, um seinen Code übersichtlicher zu gestalten.
Übersichtlich hier jedoch mit Vorsicht zu genießen, weil ein C++ Programmierer etwas anderes über übersichtlich versteht als ein alter Hase, der LISP programmiert.
Gleiches gilt dann natürlich für andere Sprachen auch.

Das ganze ist mir im Kopf umhergeschwirrt, weil in einen älteren Artikel hier in diesen Thread sich über "Klammern" ausgetobt wurden ist, und ich der Meinung war, das man Lambda-Funktionen auch in FPC nutzen könnte.
Nur hier werden eben keine Klammern, sondern sprachliche Konstrukte wie PROCEDURE oder BEGIN und END verwendet.

Das mit den "noreturn" und "noexcept" waren dann Spinnereien, die mir beim Überblicken der englischen Dokumentation des FPC Handbuches ins Augen gekommen waren, und ich nicht weiter gelesen haben.

Der eigentliche Zweck dieser Gedanken war, das sich Leute finden könnten, die mir bei der Übersetzung der Dokumentation des FPC Handbuches behilflich sein könnten, da ich auch nicht 100 % den automatisch generierten Text der Online-Translatoren traue.
Selbst deepl benötigt manchmal Hintergrund-Wissen, um die Übersetzung(en) nicht eins zu eins (1:1) zu übernehmen.

Der Rest des Artikels ist wahrlich nur Gebrabbel, und ein Versuch gewesen, mit meinen spärliches Englisch zu zeigen, das was ich unter CLOS Lambda Funktionen verstehe.

[PascalDragon]

Bitte vergebt mir mein Englisch - es ist schlecht, ja ich weiß - es ist nicht meine Hauptsprache und Englisch kenne ich nur von der Schule her, nicht jedoch als Expert mit englisch sprachlichen Potential.

It does not matter whether your English is good or bad, please only use English in the international part of the forum or at least also  provide a translation (e.g. by Google Translate). If you prefer German then use the German Lazarus Forum instead.