Hi,

As Pascal mostly well known as a safe, easy to read, and elegant language, don't you think Pascal needs named parameter? I mean for ALL kind of parameters, not just for Variants. When you have a function with many parameters having default values, you know that named parameter is desirable. For example:

function f(p1: string = ''; p2: integer = 0; p3: boolean = false);

But you only need to supply the third parameter, you still must supply the first and second ones with appropriate default values, like this:

f('', 0, true);

while with named parameter, you can do this:

f(p3 := true);

I believe it would raise Pascal's code readability. I know it has been discussed before. I know somehow the parser had been able to read such syntax. So, why don't we have the option to enable it for people who want it? Kinda a syntax switch mode.

What do you think? :)

Opinions on what constitutes readable code clearly differ :)

But as far as I know, the parser is not able to read this syntax ?

Michael.

It would probably be possible to do it by using a record with nullable fields as the parameter.

Otherwise if you want that sort of thing use Smalltalk :-)

IMO, it's not about named parameters;
furthermore, it is not about readability, but this IMO is a maintenance issue.

Think about a procedure that has two parameters and a lot of callers and you want to add a third one.

it would be nice if you could specify a default value for the new third parameter and don't have to change all the callers that use only two.

So IMO a sensible extension to the Pascal syntax could be:

if there is a initialization on the procedure declaration, the parameter is optional.

Example:

procecure P (x : integer; y : boolean; c: char := ' ');

the first two parameters are mandatory, the third is optional. Calls to P with 2 and 3 parameters are both valid.

Another extension would be:

specify the formal parameter's name on call, that is:

P (y := true, c := '*', x := 25);

which allows for a different sequence of arguments on the procedure call

but this is a different topic and should be discussed seperate from the default issue.

I guess, that all this will be limited to byvalue parameters ... not for var parameters ...

Kind regards

Bernd

Mark Morgan Lloyd wrote

It would probably be possible to do it by using a record with nullable fields as the parameter.

Yeah, that was going to be my suggestion too. I've done this many times when many parameters are optional. Use a record as parameter type. The other benefit of this is that it is future and backwards compatible. You can add or change parameters without breaking the method signature.

Regards,
Graeme

On May 27, 2017, at 4:27 PM, Graeme Geldenhuys wrote: Yeah, that was going to be my suggestion too. I've done this many times when many parameters are optional. Use a record as parameter type. The other benefit of this is that it is future and backwards compatible. You can add or change parameters without breaking the method signature.

can you show an example of this? Just curious.

Regards,
Ryan Joseph

Ryan Joseph wrote

can you show an example of this? Just curious.

In MSEgui most of the public widget methods an method properties use this
approach.
"
type
 keyeventinfoty = record
  eventkind: eventkindty;
  key,keynomod: keyty;
  chars: msestring;
  shiftstate: shiftstatesty;
  eventstate: eventstatesty;
  timestamp: longword; //usec
 end;
[...]
 twidget = class(tactcomponent,iscrollframe,iface,iassistiveclient)
[...]
   procedure dokeydown(var info: keyeventinfoty); virtual;
"
"
type
 tactionwidget = class(twidget)
[...]
   property onkeydown: keyeventty read fonkeydown write fonkeydown;

"
https://gitlab.com/mseide-msegui/mseide-msegui/blob/master/lib/common/kernel/msegui.pas https://gitlab.com/mseide-msegui/mseide-msegui/blob/master/lib/common/widgets/msewidgets.pas

Martin

Ryan Joseph wrote

> On May 27, 2017, at 4:27 PM, Graeme Geldenhuys wrote:> > Yeah, that was going to be my suggestion too. I've done this many times when many parameters are optional. Use a record as parameter type. The other benefit of this is that it is future and backwards compatible. You can add or change parameters without breaking the method signature. can you show an example of this? Just curious.

IIRC the problem is that while it's possible to initialise a record constant by named fields processed in arbitrary order, the compiler at present doesn't allow it to be done inline:

someFunction(TPoint(X:0.0; Y:0.0));

Pascal purists would probably object to that style, since what it's effectively doing is passing the parameters as an explicit list.

Somebody please correct me it I'm wrong.

I mentioned this form of “default constructor" as a sorely missing feature in FPC a couple weeks ago. Making redundant constructors for records constantly is pretty silly. If I could figure out the compiler code I would add this myself since it’s probably one of the easier things to implement.

Regards,
Ryan Joseph

Ryan Joseph wrote

> On May 27, 2017, at 5:13 PM, Mark Morgan Lloyd wrote:> > someFunction(TPoint(X:0.0; Y:0.0));> > Pascal purists would probably object to that style, since what it's effectively doing is passing the parameters as an explicit list. I mentioned this form of “default constructor" as a sorely missing feature in FPC a couple weeks ago. Making redundant constructors for records constantly is pretty silly. If I could figure out the compiler code I would add this myself since it’s probably one of the easier things to implement.

End of last month actually, I checked :-)

I was on the periphery of that discussion, since I thought I needed something similar (but turned out not to). But you might have noticed some of the APLisms that I horrify Sven with on occasion...

On May 27, 2017, at 5:29 PM, Mark Morgan Lloyd wrote: I was on the periphery of that discussion, since I thought I needed something similar (but turned out not to). But you might have noticed some of the APLisms that I horrify Sven with on occasion...

I remember he liked my idea to use TPoint(x: 1; y: 2); using the record name as the identifier. I swear I’d add this if I knew how. :)

Regards,
Ryan Joseph

2017-05-27 9:54 GMT+02:00 Michael Van Canneyt :

The parser supports it for dispatch calls on variants (both methods and properties). You even wrote that in your own article about Word automation: https://www.freepascal.org/~michael/articles/word/word.pdf ;)

Regards,
Sven

Yes, in Delphi. But I didn't know FPC also supports it ?

Michael.

2017-05-27 16:12 GMT+02:00 Michael Van Canneyt :

Yes, it does. I didn't find a testcase for it right away, but the compiler definitely contains code for this.

Regards,
Sven

You can do something similar already with source comments

SomeProc(true {p3})

or

SomeProc({p3} true);

But obviously the compiler doesn't check it.

Problem is it increases the verbosity of the code, and how would the compiler determine when to check these and when not to... If you check this all the time it makes the language much more verbose and tedious for small functions like inttostr that you use all the time.

IMO though it does improve readability in long functions with lots of parameters, like windows api style procedures that have 5 or more parameters and you can't figure out which param is which

That will not work. p3 in his example is the 3rd parameter. You are only passing one parameter, so that will then become p1's value. And if the types don't match, you'll get a compiler error.

Optional parameters can only be at the end of the parameter list, and always from left-to-right.

Regards,
Graeme

Bernd Oppolzer wrote

it would be nice if you could specify a default value for the new third parameter and don't have to change all the callers that use only two.

[snip]

procecure P (x : integer; y : boolean; c: char := ' '); the first two parameters are mandatory, the third is optional. Calls to P with 2 and 3 parameters are both valid.

You realize you can already do this, right?

See https://www.freepascal.org/docs-html/ref/refsu64.html#x176-19800014.4.1

IMO though it does improve readability in long functions with lots of parameters, like windows api style procedures that have 5 or more parameters and you can't figure out which param is which

I had an interesting case a couple of years ago where a procedure called itself recursively, but with a couple of the parameters shifted in relative position. Messing that up when I added an extra parameter caused a difficult-to find bug, so I think that some sort of identify-by-name arrangment (I'm not saying pass-by-name because of its historical meaning) would be useful.

procedure SendMechCodeToLineASCII(mc: word; bcd, apl: boolean; crlf:
boolean= false;
                         lf: boolean= false; echo: boolean= false;
loopback: boolean= false);

..

(* CR expansion, local echo etc. Note recursive echo of LF if CR is
expanded,   *)
(* this is to keep the VM/CMS "Sixpack" happy since otherwise the first
line of *)
(* output always tries to overwrite the command that instigated it (but
with    *)
(* bits of the command showing through non-destructive spaces).
        *)
(*
        *)
(* Note intentional shift of parameter positions in the recursive call
below.   *)
     if (mc = Op_CarrierReturn) and crlf then
       SendMechCodeToLineASCII(Op_Index, bcd, apl, {crlf :=} loopback,
{lf :=} false,
                                         {echo := } true, {loopback :=}
false);
     if echo then
       PseudoEventQueue.Enqueue($80000000 + canonical(mc))
   end
end { SendMechCodeToLineASCII } ;

In our previous episode, Bernd Oppolzer said:

Yes, that is why Visual Basic had it, but I thought the whole concept was nowadays considered old fashioned and baroque.

You mean like this?

function Foo (theString: string; options: set of TFoo): boolean;
begin
end;
Foo(theString: 'foo', options: []);

Objective-C has this mandatory and it made for stupidly long method names that just looked terrible but it was optional Pascal makes it look nicer. The declaration syntax is already the same as the label for the calling syntax so that seems like a nice fit.

Regards,
Ryan Joseph

that just looked terrible but it was optional Pascal makes it look nicer. The declaration syntax is already the same as the label for the calling syntax so that seems like a nice fit.

If anything like this would be implemented, then the already existing
syntax (for variant dispatch calls) would be used which uses ":=".

Regards,
Sven

What are variant dispatch calls? Maybe something from Delphi I’m not familiar with.

That’s too bad, a single colon matches the declaration better and looks nice.

Regards,
Ryan Joseph

Except that there's no provision for setting a parameter passed as a set element to true if it's not given explicitly. Sometimes you want that, and simply inverting the meaning of a parameter results in values which appear contrived in the context of the "real world" problem being solved.

The example I gave was from a terminal emulator, where "echo", "loopback" and so on are well-accepted concepts in the industry. And having a parameter "any_character_set_as_long_as_its_not_apl" is downright silly :-)

syntax (for variant dispatch calls) would be used which uses ":=".

> > What are variant dispatch calls? Maybe something from Delphi I’m not

familiar with.

It's usually used in the context of OLE automation though one could also use this with independently of OLE/COM.
For an example see here:
https://www.freepascal.org/~michael/articles/word/word.pdf

That’s too bad, a single colon matches the declaration better and looks

nice.

An assignment is the logical choice cause you're assigning a value to a parameter. A colon is used for a declaration, which is a completely different kind of "operation".

Regards,
Sven

Hi, Sven… 
This is what I'm thinking… 
// function declarationfunction f(i: integer = 0; s: string = ''; d: double);begin // fill code hereend;// method callingf(s := 'text', 0.1); // supply the s and d paramf(0.2); // only supply the required d param// supply all the params without proper order is fine,// as long as the parameter name is givenf(d := 0.3, i := 3, s := 'text')// supply param with similar variable name is fine,// because the compiler knows what each meanss := 'another text';d := 0.4;m(s := s, d := d);  
Well, it's all inspired from Swift, but I think it suits Pascal as well.  As you said the code is already there in FPC compiler, is it possible to support such syntax in next release? At least some of them. Can we have this named parameter feature in a particular switch mode, say {$MODESWITCH NAMEDPARAMETERS} or something, so it doesn't bother anyone who don't want this feature. Thank you.
Regards,
–Mr Bee

Pada Sabtu, 27 Mei 2017 21:18, Sven Barth via fpc-pascal menulis:

2017-05-27 16:12 GMT+02:00 Michael Van Canneyt :

Yes, it does. I didn't find a testcase for it right away, but the compiler definitely contains code for this.

Regards,
Sven