Re: [fpc-devel] Explicitly named return values and implicit aliases Result
On 16.12.2020 0:07, Sven Barth wrote: No, those two are in fact correct this way. Is that the /team's/ consensus? The modeswitch Result enables the use of Result as an alias for *any* routine … Incorrect. The identifier Result does not alias the routine, it aliases the routine's return value. … that returns a result no matter if an explicit result name is set or not. I maintain that such approach is an orthogonality violation. In light that FPC provides a syntax for explicitly naming the return value, the consistent and conceptually simplest way to treat Result as the implicit/default name for that value, not as an alias to a name that cannot even be specified in most cases (non-operators). Were the presented cases examined when the current behaviour was implemented? And, if so, what were the points defending it? Does anyone actually think that there is even one good theoretical or practical reason to reject the following? ---8<--- {$modeswitch result+} // ACTUAL: 'Error: Duplicate identifier "result"' operator / (const L, R: Char) result: Char; begin result := 'Z' end; ---8<--- The compiler basically says: "You cannot name the return value Result because /I/ am naming the return value Result!". Quite ridiculous and not in the spirit of Pascal. The following behaviour also fits my narrative rather nicely: ---8<--- {$modeswitch result-} // ACTUAL: 'Fatal: Syntax error, "identifier" expected but ":" found' operator * (const L, R: Char): Char; begin exit('Z') end; ---8<--- Here, rightfully, the compiler does not threat these features as separate/orthogonal: "You opted out of the default name for the return value, do provide an explicit name." Additionally the following will fail as well (this is allowed in mode Delphi however): function Result: LongInt; That is not quite relevant for this discussion. A function and its return value are different entities. -- βþ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Explicitly named return values and implicit aliases Result
On Wed, 16 Dec 2020, Blaise--- via fpc-devel wrote: On 16.12.2020 0:07, Sven Barth wrote: No, those two are in fact correct this way. Is that the /team's/ consensus? The modeswitch Result enables the use of Result as an alias for *any* routine … Incorrect. The identifier Result does not alias the routine, it aliases the routine's return value. … that returns a result no matter if an explicit result name is set or not. I maintain that such approach is an orthogonality violation. In light that FPC provides a syntax for explicitly naming the return value, the consistent and conceptually simplest way to treat Result as the implicit/default name for that value, not as an alias to a name that cannot even be specified in most cases (non-operators). To be correct: Result is not the name of the result value, it is an alias. The following shows this: Function MyResult : String; begin Result:=''; MyResult:=''; end; You can still use the function name for the result, so "Result" is in fact an alias for the function name, which is the actual name for the result value. But I do agree with your point that it should be allowed to explicitly name Result as Result for operators, even when the Result identifier is allowed. It really makes no sense to me to forbid this. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Explicitly named return values and implicit aliases Result
Blaise--- via fpc-devel schrieb am Mi., 16. Dez. 2020, 10:14: > > The modeswitch Result enables the use of Result as an alias for *any* > routine … > > Incorrect. The identifier Result does not alias the routine, it aliases > the routine's return value. > For non operators the routine's name *is* the name of the return variable. > > … that returns a result no matter if an explicit result name is set or > not. > > I maintain that such approach is an orthogonality violation. In light that > FPC provides a syntax for explicitly naming the return value, the > consistent and conceptually simplest way to treat Result as the > implicit/default name for that value, not as an alias to a name that cannot > even be specified in most cases (non-operators). > For non operators the name of the real result value *is* the name of the routine and Result is the alias. Operators don't have names (in the classical sense, internally they have one of course), thus for the modes without Result modeswitch a way had to be introduced to specify the name of the variable containing the result. > Were the presented cases examined when the current behaviour was > implemented? And, if so, what were the points defending it? Does anyone > actually think that there is even one good theoretical or practical reason > to reject the following? > I doubt that was examined back then, but right now the behavior is consistent and I see no need to change it. > Additionally the following will fail as well (this is allowed in mode > Delphi however): > > function Result: LongInt; > > That is not quite relevant for this discussion. A function and its return > value are different entities. > Yes, it is relevant for this discussion, because it's the same piece of code in the compiler that handles this. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Explicitly named return values and implicit aliases Result
On Wed, 16 Dec 2020 10:24:39 +0100 (CET) Michael Van Canneyt via fpc-devel wrote: >[...] > Function MyResult : String; > > begin >Result:=''; >MyResult:=''; > end; > > You can still use the function name for the result, so "Result" is in > fact an alias for the function name, which is the actual name for the > result value. That is not entirely correct. Function MyResult : String; begin Result:=Result; // the current result MyResult:=MyResult; // recursive call end; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Explicitly named return values and implicit aliases Result
On 16.12.2020 12:24, Michael Van Canneyt via fpc-devel wrote: To be correct: Result is not the name of the result value, it is an alias. I did not dispute that. The important point here is: "an alias" to /what/? You can still use the function name for the result, so "Result" is in fact an alias for the function name Result is not "an alias for the function name" because you cannot use Result to refer to the function: ---8<--- function Foo: Integer; var X: function : Integer; begin Result(); // ERROR X := Result; // ERROR end; ---8<--- the function name, which is the actual name for the result value. I can get behind this notion; however, within the function, that name is overloaded. Thus, we should not say, like Sven did, that Result aliases the function (name); we should say, like I did, that it aliases the return value (name). But, conceptually, I would rather look at the function name resolving to the return value as a backward-compatible alias, and say that Result is the true (default) name for the return value. Such notion fits modern usage. I do agree with your point that it should be allowed to explicitly name Result as Result for operators, even when the Result identifier is allowed. The score thus far: 1:1. -- βþ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Explicitly named return values and implicit aliases Result
On Wed, 16 Dec 2020, Blaise--- via fpc-devel wrote: On 16.12.2020 12:24, Michael Van Canneyt via fpc-devel wrote: To be correct: Result is not the name of the result value, it is an alias. But, conceptually, I would rather look at the function name resolving to the return value as a backward-compatible alias, and say that Result is the true (default) name for the return value. Such notion fits modern usage. So, let's say that: The function result can be assigned using 2 identifiers: * The Result identifier. * The name of the function. I do agree with your point that it should be allowed to explicitly name Result as Result for operators, even when the Result identifier is allowed. The score thus far: 1:1. Well, it's not exactly a contest. We can of course consider changing the current behaviour in the future, as far as I know there is no urgency in this ATM. There are other, more urgent tasks... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Explicitly named return values and implicit aliases Result
On 2020-12-16 12:25, Blaise--- via fpc-devel wrote: On 16.12.2020 12:24, Michael Van Canneyt via fpc-devel wrote: To be correct: Result is not the name of the result value, it is an alias. I did not dispute that. The important point here is: "an alias" to /what/? You can still use the function name for the result, so "Result" is in fact an alias for the function name Result is not "an alias for the function name" because you cannot use Result to refer to the function: ---8<--- function Foo: Integer; var X: function : Integer; begin Result(); // ERROR X := Result; // ERROR end; ---8<--- It is a _local_ alias for the name of the _currently_executed_ function which is valid just within the scope of that function. When invoking the function recursively, you refer to _another_ instance of that function and thus the alias is not valid at that point in time, because it becomes an alias again only when the recurrently called function starts. Thus it's equivalent to the following example (it compiles due to {$MODE TP}; in other modes the local can be replaced with another name with the same effects): {$MODE TP} function Foo: Integer; var X: Integer absolute Foo; begin X := 123; end; begin WriteLn (Foo); end. the function name, which is the actual name for the result value. I can get behind this notion; however, within the function, that name is overloaded. Thus, we should not say, like Sven did, that Result aliases the function (name); we should say, like I did, that it aliases the return value (name). But, conceptually, I would rather look at the function name resolving to the return value as a backward-compatible alias, and say that Result is the true (default) name for the return value. Such notion fits modern usage. Modern or not - use of the function name for assignment of the return value is part of Pascal definition, isn't it? What's the point of changing the "true name"? Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Explicitly named return values and implicit aliases Result
Michael Van Canneyt via fpc-devel schrieb am Mi., 16. Dez. 2020, 12:47: > We can of course consider changing the current behaviour in the future, as > far as I > know there is no urgency in this ATM. There are other, more urgent tasks... > I agree. Please concentrate on anonymous functions and don't change things that don't need to be changed *now*. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Method pointers to RECORD methods
The patch http://hg.blaise.ru/public/fpc/rev/0a8aff8d8273 (attached) fixes the following: ---8<--- {$Mode Delphi} type R = record var X: Integer; function Foo: Integer; end; function R.Foo: Integer; begin result := X end; var F: function : Integer of object; Z: R = (X:42); begin // EXPECTED: gets compiled // ACTUAL: 'Error: Incompatible types' F := Z.Foo; writeln( F() = 42 ) end. ---8<--- The patch does not check for m_delphi: I did not came up with a case where that would make a semantic difference. -- βþ # HG changeset patch # User Blaise.ru # Date 1608125930 -10800 ! tprocdef.is_methodpointer: allow method pointers to RECORD methods diff -r 6a8b4a8fc96e -r 8dc95aab5009 symdef.pas --- a/symdef.pasTue Dec 15 20:45:13 2020 +0300 +++ b/symdef.pasWed Dec 16 16:38:50 2020 +0300 @@ -6636,7 +6636,7 @@ begin { don't check assigned(_class), that's also the case for nested procedures inside methods } -result:=(owner.symtabletype=ObjectSymtable)and not no_self_node; +result:=(owner.symtabletype in [recordsymtable,ObjectSymtable]) and not no_self_node; end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Generic instantiations as result types of procedural types
The patch http://hg.blaise.ru/public/fpc/rev/544a934d262e (attached) fixes the following: ---8<--- {$Mode Delphi} type G = class var X: T; // EXPECTED: gets compiled // ACTUAL: 'Error: Generics without specialization cannot be used as a type for a variable' class var F: function(const X: T) : G of object; function Foo(const X: T): G; end; function G.Foo(const X: T): G; begin result := G.Create; result.X := X end; begin G.F := G.Create.Foo; writeln( G.F(42).X = 42 ); end. ---8<--- -- βþ # HG changeset patch # User Blaise.ru # Date 1608134554 -10800 ! procvar_dec: allow generic instantiations as result types of procedural types diff -r 0a8aff8d8273 -r 544a934d262e ptype.pas --- a/ptype.pas Wed Dec 16 16:38:50 2020 +0300 +++ b/ptype.pas Wed Dec 16 19:02:34 2020 +0300 @@ -1587,7 +1587,7 @@ if is_func then begin consume(_COLON); -single_type(pd.returndef,[]); +single_type(pd.returndef,[stoAllowSpecialization]); end; if try_to_consume(_OF) then begin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Method pointers to RECORD methods
Am 16.12.2020 um 15:01 schrieb Blaise--- via fpc-devel: The patch http://hg.blaise.ru/public/fpc/rev/0a8aff8d8273 (attached) fixes the following: ---8<--- {$Mode Delphi} type R = record var X: Integer; function Foo: Integer; end; function R.Foo: Integer; begin result := X end; var F: function : Integer of object; Z: R = (X:42); begin // EXPECTED: gets compiled // ACTUAL: 'Error: Incompatible types' F := Z.Foo; writeln( F() = 42 ) end. ---8<--- The patch does not check for m_delphi: I did not came up with a case where that would make a semantic difference. Hadn't thought that Delphi allows this... anyway, applied in r47794. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic instantiations as result types of procedural types
Am 16.12.2020 um 17:09 schrieb Blaise--- via fpc-devel: The patch http://hg.blaise.ru/public/fpc/rev/544a934d262e (attached) fixes the following: ---8<--- {$Mode Delphi} type G = class var X: T; // EXPECTED: gets compiled // ACTUAL: 'Error: Generics without specialization cannot be used as a type for a variable' class var F: function(const X: T) : G of object; function Foo(const X: T): G; end; function G.Foo(const X: T): G; begin result := G.Create; result.X := X end; begin G.F := G.Create.Foo; writeln( G.F(42).X = 42 ); end. ---8<--- Applied in r47795. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel