Re: [fpc-pascal] Named optional arguments
> On Dec 1, 2021, at 4:56 AM, Sven Barth wrote: > > If you don't allow to skip parameters then this feature can be considered > absolutely useless. Who would voluntarily write more when many users already > cry about Pascal being so verbose? I thought the option of improved readability made sense for a language like Pascal. > >> Yes I understand that the overloading happens after parsing. In your first >> example if arbitrary order was allowed new overloading rules would need to >> be applied so that you got an ambiguous function error. Not a big deal to >> resolve that I would think but it doesn't have to go in that direction >> either. >> >> Personally I'm not in favor or changing the overloading rules, just that >> some calls were easier to read by glancing over them. In fact I have seen >> IDEs which have a feature which inserts the param name into the editor for >> this very reason. > > You still don't get it. This is not about "changing the overloading rules" > but about this feature fitting into the existing overload selection > functionality. No I really do understand what the situation is if you can believe me. I don't see this is a big problem or too complicated to tackle but if you really dislike the idea so much then we'll leave it at that. There's more important potential features to work on anyways. btw kind of off topic did you like my idea of default properties for records so we can implement smart pointers? I got a good chunk of that done months ago but never heard anything about it... Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
Am 28.11.2021 um 14:21 schrieb Ryan Joseph via fpc-pascal:
On Nov 28, 2021, at 7:01 PM, Sven Barth wrote:
Anything that relates to picking functions *must* be part of the overload
handling. You can easily see this with your named argument proposal when not
all arguments are named (and then the compiler also needs to check that unnamed
parameters aren't used for named ones as well, this gets more complicated if
the overloads have different argument names).
You should have already learned this lesson when I pointed you in the right
direction for the implicit function specializations.
I'm not proposing we necessarily allow the reordering of arguments or allow
omitting of values. In the simplest scenario they're just optional names but
the parameters still need to be provided in the correct order. Very simply to
make reading long functions easier at the call site.
If you don't allow to skip parameters then this feature can be
considered absolutely useless. Who would voluntarily write more when
many users already cry about Pascal being so verbose?
Yes I understand that the overloading happens after parsing. In your first
example if arbitrary order was allowed new overloading rules would need to be
applied so that you got an ambiguous function error. Not a big deal to resolve
that I would think but it doesn't have to go in that direction either.
Personally I'm not in favor or changing the overloading rules, just that some
calls were easier to read by glancing over them. In fact I have seen IDEs which
have a feature which inserts the param name into the editor for this very
reason.
You still don't get it. This is not about "changing the overloading
rules" but about this feature fitting into the existing overload
selection functionality.
Take the following example:
=== code begin ===
procedure Test(aArg1: String; aArg2: LongInt = 42; aArg3: String = '');
procedure Test(aArg1: LongInt; aArg2: String = '');
// somewhere else
Test('Foobar', aArg3 := 'Hello World');
=== code end ===
Now when the compiler encounters the symbol "Test" it roughly plays out
like this:
1. Detect that "Test" is a procsym
2. Collect all suitable overloads
3. for each overload iterate all provided parameters
1. is it a named parameter?
1. does the name match a named parameter after the last unnamed or
named one?
1. no -> not a suitable overload
2. yes -> retrieve default value of parameters between last one
and this one and use this parameter value (and make sure that the value
is suitable for the parameter type)
2. name matches an existing previous parameter? -> not a suitable
overload
3. duplicate name? -> report error about duplicate parameter use
(could maybe be done while parsing already)
4. name does not match any parameter? -> not a suitable overload
2. parameter value suitable for the parameter? (essentially existing
overload checks)
4. if no suitable overload was found then report found overloads and
error out
5. if multiple suitable overloads were found then reprot found suitable
overloads and error out
This is of course a simplification, but you can easily see that it needs
to fit snuggly into the overload selection code provided by
tcallcandidates, because it needs to handle cases with mixed named and
unnamed parameters.
As an aside, is it even useful to allow arbitrary parameter order? I don't
recall ever wanting this and would open the door to some functions being called
in different order across a codebase, which sounds like a big problem unto
itself (C# allows this btw).
You provided that as a possible suggestion, so I went with it to humor you.
Additional drawback of named arguments: refactoring a routine's
parameter names would also mean that ore can have problems with
backwards compatibility if one decides to rename a parameter (because it
turned out to be badly named), cause this would lead to compile time
errors once the parameter name of the declaration is changed, but not at
the call sites (and now imagine one of us changing a parameter name in
some important RTL function and users using that in their code).
I don't care that other programming languages think of this as a nice
feature, *I* don't.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
Am 28.11.2021 um 12:52 schrieb Ryan Joseph via fpc-pascal: On Nov 28, 2021, at 4:18 PM, Mattias Gaertner via fpc-pascal wrote: What do you mean? Is there already some call by arg names in some mode(switch)? I mean all the plumbing is there so the feature could easily be extended from IDispatch to work with normal function calls. The only thing that is there is the parsing and that is the smallest part of implementing this functionality. You absolutely underestimate what is involved with this. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 28, 2021, at 7:01 PM, Sven Barth wrote: > > Anything that relates to picking functions *must* be part of the overload > handling. You can easily see this with your named argument proposal when not > all arguments are named (and then the compiler also needs to check that > unnamed parameters aren't used for named ones as well, this gets more > complicated if the overloads have different argument names). > > You should have already learned this lesson when I pointed you in the right > direction for the implicit function specializations. > I'm not proposing we necessarily allow the reordering of arguments or allow omitting of values. In the simplest scenario they're just optional names but the parameters still need to be provided in the correct order. Very simply to make reading long functions easier at the call site. Yes I understand that the overloading happens after parsing. In your first example if arbitrary order was allowed new overloading rules would need to be applied so that you got an ambiguous function error. Not a big deal to resolve that I would think but it doesn't have to go in that direction either. Personally I'm not in favor or changing the overloading rules, just that some calls were easier to read by glancing over them. In fact I have seen IDEs which have a feature which inserts the param name into the editor for this very reason. As an aside, is it even useful to allow arbitrary parameter order? I don't recall ever wanting this and would open the door to some functions being called in different order across a codebase, which sounds like a big problem unto itself (C# allows this btw). Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
Ryan Joseph via fpc-pascal schrieb am So., 28. Nov. 2021, 03:12: > > > > On Nov 27, 2021, at 5:00 PM, Sven Barth > wrote: > > > > The compiler does not know which routine is called upon parsing the > parameter declarations (which would mean that error reports would need to > be deferred until the lookup of the routine failed). > > My idea was to not actually have it affect overloading except in the case > where the param names don't match which would ignore the call (so in your > example below nothing changes). > > Otherwise if the name was actually part of the overloading we would have > to allow functions with the same parameter type but different names, i.e.: > > procedure Foo(Arg1: String = ''); > procedure Foo(Arg2: String = ''); > > and that would be a big change to the language and have all sorts of > implications. > > So it's really just a minor hint to make the call more readable in the > case of long function names. > Anything that relates to picking functions *must* be part of the overload handling. You can easily see this with your named argument proposal when not all arguments are named (and then the compiler also needs to check that unnamed parameters aren't used for named ones as well, this gets more complicated if the overloads have different argument names). You should have already learned this lesson when I pointed you in the right direction for the implicit function specializations. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
Ryan Joseph via fpc-pascal schrieb am So., 28. Nov. 2021, 05:32: > > > > On Nov 27, 2021, at 5:03 PM, Sven Barth > wrote: > > > > candidates:=tcallcandidates.create(sym:=symtableprocentry, > st:=symtableproc,ppn:=left, > ignorevisibility:=ignorevisibility,allowdefaultparas:=not(nf_isproperty in > flags),objcidcall:=cnf_objc_id_call in > callnodeflags,explicitunit:=cnf_unit_specified in > callnodeflags,searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], > anoninherited:=cnf_anon_inherited in > callnodeflags,spezcontext:=spezcontext); > > > > So you've gained *nothing*. > > I wouldn't say nothing but it's still really hard to read. My only thought > there was that it would open the door for some syntax coloring on the > parameter name so you can scan them easier. > Lazarus already highlights commas differently, so one can easily differentiate the parameters. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 28, 2021, at 4:18 PM, Mattias Gaertner via fpc-pascal > wrote: > > What do you mean? Is there already some call by arg names in some > mode(switch)? I mean all the plumbing is there so the feature could easily be extended from IDispatch to work with normal function calls. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
On 28/11/2021 10:18, Mattias Gaertner via fpc-pascal wrote: On 26.11.21 04:10, Ryan Joseph via fpc-pascal wrote: [...]The majority of the infrastructure is already there so it needs to merely be extended. What do you mean? Is there already some call by arg names in some mode(switch)? No, it's only there for IDispatch support: https://stackoverflow.com/questions/885942/named-optional-parameters-in-delphi Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
On 26.11.21 04:10, Ryan Joseph via fpc-pascal wrote: [...]The majority of the infrastructure is already there so it needs to merely be extended. What do you mean? Is there already some call by arg names in some mode(switch)? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 27, 2021, at 5:03 PM, Sven Barth wrote: > > candidates:=tcallcandidates.create(sym:=symtableprocentry, > st:=symtableproc,ppn:=left, > ignorevisibility:=ignorevisibility,allowdefaultparas:=not(nf_isproperty in > flags),objcidcall:=cnf_objc_id_call in > callnodeflags,explicitunit:=cnf_unit_specified in > callnodeflags,searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], > anoninherited:=cnf_anon_inherited in callnodeflags,spezcontext:=spezcontext); > > So you've gained *nothing*. I wouldn't say nothing but it's still really hard to read. My only thought there was that it would open the door for some syntax coloring on the parameter name so you can scan them easier. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 27, 2021, at 5:00 PM, Sven Barth wrote: > > The compiler does not know which routine is called upon parsing the parameter > declarations (which would mean that error reports would need to be deferred > until the lookup of the routine failed). My idea was to not actually have it affect overloading except in the case where the param names don't match which would ignore the call (so in your example below nothing changes). Otherwise if the name was actually part of the overloading we would have to allow functions with the same parameter type but different names, i.e.: procedure Foo(Arg1: String = ''); procedure Foo(Arg2: String = ''); and that would be a big change to the language and have all sorts of implications. So it's really just a minor hint to make the call more readable in the case of long function names. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
On 27/11/2021 03:32, Ryan Joseph via fpc-pascal wrote: 1) Original form (the compiler doesn't use spaces between punctuation). Very difficult to read if nothing else because the lack of spaces but it's also not clear at all which params are which. Even code tools are going to not help very much unless they can hilight the parameters in the editor. That's exactly what Lazarus does: place your cursor on any of the parameters and press ctrl-shift-space. It will show you the declaration with the current parameter in bold. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
Am 27.11.2021 um 03:32 schrieb Ryan Joseph via fpc-pascal: On Nov 26, 2021, at 4:20 PM, Ryan Joseph wrote: It's mainly useful when reading code so you don't need to review the function definition, using code tools or any other method. I've been enjoying it in other languages when it's not compulsory and FPC already supports the syntax so I thought it would be low hanging fruit. I wanted to add a little case study from the compiler itself to see how to make some really long function more readable. 1) Original form (the compiler doesn't use spaces between punctuation). Very difficult to read if nothing else because the lack of spaces but it's also not clear at all which params are which. Even code tools are going to not help very much unless they can hilight the parameters in the editor. Either way you're going to be spending time try to figure this one out. candidates:=tcallcandidates.create(symtableprocentry,symtableproc,left,ignorevisibility, not(nf_isproperty in flags),cnf_objc_id_call in callnodeflags,cnf_unit_specified in callnodeflags, callnodeflags*[cnf_anon_inherited,cnf_inherited]=[],cnf_anon_inherited in callnodeflags,spezcontext); 2) Adding some line breaks helps a lot but it's still not clear what some of the params are unless you jump to the function definition or get a tool tip on the constructor and then even so you need to count the params to see which is which, and this takes time and effort. candidates:=tcallcandidates.create(symtableprocentry, symtableproc, left, ignorevisibility, not(nf_isproperty in flags), cnf_objc_id_call in callnodeflags, cnf_unit_specified in callnodeflags, callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], cnf_anon_inherited in callnodeflags, spezcontext); 3) Clearly defined names each on their own line is obviously the easiest to read at a glance. Even if no line breaks were present the editor could style the param names a different color and they would be easy to read. candidates:=tcallcandidates.create(sym:=symtableprocentry, st:=symtableproc, ppn:=left, ignorevisibility:=ignorevisibility, allowdefaultparas:=not(nf_isproperty in flags), objcidcall:=cnf_objc_id_call in callnodeflags, explicitunit:=cnf_unit_specified in callnodeflags, searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], anoninherited:=cnf_anon_inherited in callnodeflags, spezcontext:=spezcontext); The use case is irrelevant, because a) if named arguments would be used in the compiler it would be used as candidates:=tcallcandidates.create(sym:=symtableprocentry, st:=symtableproc,ppn:=left, ignorevisibility:=ignorevisibility,allowdefaultparas:=not(nf_isproperty in flags),objcidcall:=cnf_objc_id_call in callnodeflags,explicitunit:=cnf_unit_specified in callnodeflags,searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], anoninherited:=cnf_anon_inherited in callnodeflags,spezcontext:=spezcontext); So you've gained *nothing*. b) more often then not you need to look at the declaration or even the implementation anyway to know what the function is doing or expecting due the lack of up-to-date and complete documentation Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
Am 26.11.2021 um 05:10 schrieb Ryan Joseph via fpc-pascal: This was discussed before some years ago with no conclusion (https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg46280.html) but I'd like to bring it up again. Can we consider extending the variant dispatch call named parameters to normal functions? The majority of the infrastructure is already there so it needs to merely be extended. This is what the syntax would look like: SetupCanvas(width := 500, height := 500, eventCallback := @HandleCanvasEvents, options := [TCanvasOption.VSync]); The reason for this is of course to handle functions with many parameters so we don't need to look at the function definition to know which params mean what thing. C# has effectively added optional named parameters along with other languages I use and I consider this a solid development at this point. My complaints come with languages like Swift where the parameter names are meant to be part of the function signature and really clutter up the language in my opinion so I'd like to avoid that by making it opt-in, like C#. The basic idea: - Opt-in design so if you name the first parameter in a function all following parameters must be named, and the inverse, if the first parameter is not named the following parameters can not be named either. - Consider the parameter name during overloading resolution so that even if the values are correct the names must match also. - Enabled with a mode switch? - Parameters can be specified in any order? I'm against it for multiple reasons: The compiler does not know which routine is called upon parsing the parameter declarations (which would mean that error reports would need to be deferred until the lookup of the routine failed). What would be called in this situation: // unit A procedure Foo(aArgStr: String = ''); overload; // unit B procedure Foo(aArgInt: LongInt = 0; aArgStr: String = ''); overload; // unit C Foo(aArgStr = 'Foo'); (Side note: yes, if no parameter would be given, the compiler would already complain about an ambigous call) This would also introduce a possibility of subtle bugs, in addition to those that already exist for overloading. Take the example above, but without the "overload" directive: If the uses-clause in unit C would be "UnitA, UnitB" then the "Foo" from unit B would be called and if it would be "UnitB, UnitA" then the one from unit A would be called. Without named arguments there would be a compile error due to a mismatched argument. Also this complicates overload selection (especially with an out of order use of the parameters) and overload selection is already complicated enough. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 26, 2021, at 4:20 PM, Ryan Joseph wrote: > > It's mainly useful when reading code so you don't need to review the function > definition, using code tools or any other method. I've been enjoying it in > other languages when it's not compulsory and FPC already supports the syntax > so I thought it would be low hanging fruit. I wanted to add a little case study from the compiler itself to see how to make some really long function more readable. 1) Original form (the compiler doesn't use spaces between punctuation). Very difficult to read if nothing else because the lack of spaces but it's also not clear at all which params are which. Even code tools are going to not help very much unless they can hilight the parameters in the editor. Either way you're going to be spending time try to figure this one out. candidates:=tcallcandidates.create(symtableprocentry,symtableproc,left,ignorevisibility, not(nf_isproperty in flags),cnf_objc_id_call in callnodeflags,cnf_unit_specified in callnodeflags, callnodeflags*[cnf_anon_inherited,cnf_inherited]=[],cnf_anon_inherited in callnodeflags,spezcontext); 2) Adding some line breaks helps a lot but it's still not clear what some of the params are unless you jump to the function definition or get a tool tip on the constructor and then even so you need to count the params to see which is which, and this takes time and effort. candidates:=tcallcandidates.create(symtableprocentry, symtableproc, left, ignorevisibility, not(nf_isproperty in flags), cnf_objc_id_call in callnodeflags, cnf_unit_specified in callnodeflags, callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], cnf_anon_inherited in callnodeflags, spezcontext); 3) Clearly defined names each on their own line is obviously the easiest to read at a glance. Even if no line breaks were present the editor could style the param names a different color and they would be easy to read. candidates:=tcallcandidates.create(sym:=symtableprocentry, st:=symtableproc, ppn:=left, ignorevisibility:=ignorevisibility, allowdefaultparas:=not(nf_isproperty in flags), objcidcall:=cnf_objc_id_call in callnodeflags, explicitunit:=cnf_unit_specified in callnodeflags, searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], anoninherited:=cnf_anon_inherited in callnodeflags, spezcontext:=spezcontext); 4) For contrast here's a bad example of named params which we want to avoid. Languages like Swift encourage this kind of thing and I think it's less readable and adds clutter. pt := MakePoint(x:= 1, y := 2); // cluttered and doesn't add any useful information pt := MakePoint(1, 2);// normal calling syntax, easy to read and clean Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 26, 2021, at 3:31 PM, Michael Van Canneyt > wrote: > > That seems like a fake argument: Of course you need to look, because you need > the names ? > Secondly, the IDE will simply tell you what the names are when the cursor is > on them. It's mainly useful when reading code so you don't need to review the function definition, using code tools or any other method. I've been enjoying it in other languages when it's not compulsory and FPC already supports the syntax so I thought it would be low hanging fruit. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
On Fri, 26 Nov 2021, Ryan Joseph via fpc-pascal wrote: This was discussed before some years ago with no conclusion (https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg46280.html) but I'd like to bring it up again. Can we consider extending the variant dispatch call named parameters to normal functions? The majority of the infrastructure is already there so it needs to merely be extended. This is what the syntax would look like: SetupCanvas(width := 500, height := 500, eventCallback := @HandleCanvasEvents, options := [TCanvasOption.VSync]); The reason for this is of course to handle functions with many parameters so we don't need to look at the function definition to know which params mean what thing. That seems like a fake argument: Of course you need to look, because you need the names ? Secondly, the IDE will simply tell you what the names are when the cursor is on them. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
