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

[MarkMLl]

In my opinion both vFunc; and vProc; should not compile in mode ObjFPC (or FPC), cause there the point is that brackets should be used when calling parameter-less functions. 🤔

I just want to reinforce that we are in complete agreement as far as to when parentheses should be used/required.

For what it's worth, I agree as well. Having said which, I find appended empty parentheses useful as a way of emphasising both function and procedure names in documentation, but I don't think it's necessary to /require/ parentheses when a procedure is invoked in code... although it's useful to /permit/ them.

MarkMLl

[440bx]

I don't think it's necessary to /require/ parentheses when a procedure is invoked in code... although it's useful to /permit/ them.

MarkMLl

Requiring them is what solves the ambiguities in their use. 

C has it right.  A function identifier without parentheses is the address of the function, effectively a runtime compiler constant, with the parenthesis, it is a function call.  That's crystal clear.

In Pascal, it is currently a mess.   Sometimes the presence of parentheses makes a difference and sometimes they don't.  Because of that, it sometimes requires the use of the @ operator to distinguish between a call and a reference.  What a mess!

[MarkMLl]

I don't think it's necessary to /require/ parentheses when a procedure is invoked in code... although it's useful to /permit/ them.

Requiring them is what solves the ambiguities in their use. 

C has it right.  A function identifier without parentheses is the address of the function, effectively a runtime compiler constant, with the parenthesis, it is a function call.  That's crystal clear.

In Pascal, it is currently a mess.   Sometimes the presence of parentheses makes a difference and sometimes they don't.  Because of that, it sometimes requires the use of the @ operator to distinguish between a call and a reference.  What a mess!

It shouldn't be necessary to /require/ parentheses for invocation of a procedure (as distinct from a function) without parameters, since no result is returned.

However that might necessitate a hard look at more fundamental aspects of the language, in particular whether a function result can be discarded silently.

MarkMLl

[TRon]

It shouldn't be necessary to /require/ parentheses for invocation of a procedure (as distinct from a function) without parameters, since no result is returned.

It is not about the function returning anything but indicating that the intention is to pass zero arguments to the function (as a result invoking the function instead of returning its address).

[paule32]

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.  

[MarkMLl]

It shouldn't be necessary to /require/ parentheses for invocation of a procedure (as distinct from a function) without parameters, since no result is returned.

It is not about the function returning anything but indicating that the intention is to pass zero arguments to the function (as a result invoking the function instead of returning its address).

The problem is that it becomes impossible to distinguish between an invocation of a parameterless procedure and a reference to a function taking no parameters (or with parameters all assumed to be their default values).

Modula-2 both assumes that function invocation always has parentheses, that function results cannot be implicitly discarded, and that there are far fewer situations where automatic type transfers ("casts" etc.) are applied. Collectively, that avoids this kind of ambiguity.

MarkMLl

[MarkMLl]

I something in my mind ... that I have read "noreturn" in the sources and documentation of FPC.

Citation required, or we'll assume that you're writing high fantasy.

MarkMLl

[TRon]

The problem is that it becomes impossible to distinguish between an invocation of a parameterless procedure and a reference to a function taking no parameters (or with parameters all assumed to be their default values).

Modula-2 both assumes that function invocation always has parentheses, that function results cannot be implicitly discarded, and that there are far fewer situations where automatic type transfers ("casts" etc.) are applied. Collectively, that avoids this kind of ambiguity.

In that case I either misunderstood your argument that I responded to or I misunderstand the use of the parenthesis. When used it makes sure the procedure or function is invoked (even required when stored in a variable and not having any parameters), which seems consistent to me.

To me the absence of the parenthesis is what is confusing to me (I try to avoid that).

[MarkMLl]

In that case I either misunderstood your argument that I responded to or I misunderstand the use of the parenthesis. When used it makes sure the procedure or function is invoked (even required when stored in a variable and not having any parameters), which seems consistent to me.

To me the absence of the parenthesis is what is confusing to me (I try to avoid that).

Yes, but in the case of Modula-2 they're not needed because the overall behaviour of the language has been tightened up. They probably /are/ needed in Pascal because the function result can be discarded.

There's still the very unpleasant case of a function which can return a reference to another function with the same parameter list ("signature").

MarkMLl

[440bx]

It doesn't matter whether or not the function result can be discarded.  "Consider" a procedure a function whose result is discarded (which is what C does) and it becomes obvious that the problem has nothing to do with what happens to the result.

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.  In a correctly designed language, parentheses present = function/procedure invocation, parentheses NOT present = function/procedure reference (the address of the code.)  It's that simple.

Another flaw in Pascal that contributes to the problem is Pascal's mechanism used to assign a result to a function.  Specifically, in standard pascal the return value is specified using <function_identifier> := <some_value>, _that_ causes a problem because the function_identifier should NOT be an lvalue (because by definition, the identifier should be the address of the code, which cannot change.)

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.)

[MarkMLl]

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.)

It's done similarly in Modula-2. Could we /please/ stick to Wirth's languages, mentioning C risks antagonising the core team hence making the likelihood of a fix even more remote :-)

MarkMLl

[440bx]

It's done similarly in Modula-2. Could we /please/ stick to Wirth's languages, mentioning C risks antagonising the core team hence making the likelihood of a fix even more remote :-)

MarkMLl

I have nothing against sticking to Wirthian languages but, I cannot refer to Modula-2 because I simply don't remember how these things are implemented in that language. 

Also, I don't think the core team will be put off by references to the C language given that many of them know C and some of them use it every day.  Also, it's not every day I can say that C got something right (it's usually the opposite.)

[paule32]

why does Modula-2 use strickt upperCase keywords like:

PROCEDURE   or
FUNCTION
?

before Modula-2, Turbo Pascal was caseInsentive, so you could write keywords like:

PrOCeDuRE  or
fUnCTion
?

For me the new comer Modula-2 is very not comfortable.

But, I can remember me, that under MS-DOS gave it a Tool Oberon.exe - a Windows 3.1 like desktop that you could extend with the Language Oberon - or - Modula - I never mind me the differences.
Is Oberon a Modula-2 dialect ?

[MarkMLl]

why does Modula-2 use strickt upperCase keywords like:

PROCEDURE   or
FUNCTION
?

before Modula-2, Turbo Pascal was caseInsentive, so you could write keywords like:

PrOCeDuRE  or
fUnCTion
?

For me the new comer Modula-2 is very not comfortable.

But, I can remember me, that under MS-DOS gave it a Tool Oberon.exe - a Windows 3.1 like desktop that you could extend with the Language Oberon - or - Modula - I never mind me the differences.
Is Oberon a Modula-2 dialect ?

Because when Wirth designed Pascal (in a hurry, for political reasons) a lot of machines still used 6-bit character sets so there was no point distinguishing between upper and lower case,

Modula-2 basically fell in line with the majority convention.

Oberon is a separate language, as a cursory reference to Wikipedia or a minimal websearch would show you.

MarkMLl

[BrunoK]

Because when Wirth designed Pascal (in a hurry, for political reasons) a lot of machines still used 6-bit character sets so there was no point distinguishing between upper and lower case,

MarkMLl

in a hurry, for political reasons : source please.

What political reasons ?