| Store | Cart

Re: [TCLCORE] TIP #457 - Named Parameters Implementation

From: Dipl. Ing. Sergey G. Brester <seb...@users.sourceforge.net>
Wed, 18 Jan 2017 18:20:14 +0100
 

Hello, 

I totally agree with you what about currently solution suggested in TIP
(and current implementation of Mathieu Lafon). 

Additionally a pair thoughts to the suggested syntax (sentinel prefix
for command like -cmd): 

- as you've correctly said already, pure "-" sentinel would be
conflicted with many current solutions;
- {*}cmd is not allowed, because ambiguous with current expand
implementation (try `{*}{puts ok}`);

I've already suggested another solution that uses sentinel not as
command-prefix, but inside or before arguments (like `myfunc "fixed-1"
"fixed-2" {$}name $name place $place`). 
Please see ../tcl-core/16590/ [3] 

Pros: 

- it would be a proper tclish way;
- it can be combined with expand syntax `{*}`
- you can choice the position of named-args in call more precise by
ambiguous args. It is important because the usage of named arguments
arranges extremely usage of many defaults in proc declaration (and can
be additionally combined with args). Example:
## declaration:
proc myfunc { place {fixed1 1} {fixed2 2} {fixed3 3} {name nothing} }
{...}
## following will provide "fixed-1" into argument `fixed1`, because
argument `place` specified as named...
myfunc "fixed-1" "fixed-2" {$}name $name place $place; # no-error,
fixed3 become default value
## and compare with:
myfunc "fixed-1" {$}place $place; # fixed2, fixed3 and name become
default values
- a full-compiled implementation may be relative easy provided to do
that (something like INST_INVOKE_REPLACE). 

Regards,
sebres. 

18.01.2017 17:17, Peter da Silva wrote: 

> Gentlemen, > > I've been discussing the TIP #457 with Karl, and it seems to be taking things in a direction that doesn't really address the intent of the FlightAware Tcl Bounty. > > A central part of the Tcl bounty for named parameters is to produce a solution that encourages people to use named parameters. It needs to be something that fits well into existing Tcl usage, without a lot of boilerplate exposed to the caller or implementor. > > That's a key purpose of the requirement that named parameters don't require changes to the definition of the proc. But the flip side is just as important... calling a proc using named parameters should seem natural and as similar as possible to the way existing named parameters are used. > > And that's a problem, because TIP #457 unfortunately does not describe something that is likely to have a high uptake among Tcl developers. It makes the process of calling a proc with named parameters verbose, which will tend to discourage its use. > > So... some additional points to bear in mind: > > 1. There's really no need for a huge amount of flexibility in the "new syntax". Either existing positional style, or the new named style using the information provided in the proc definition, are the only alternatives needed. Extensions like the one implied by "call -opts -npos 1" are really kind of overkill. > > 2. On the other hand, some kind of flag on the call of a proc is ok, and is probably required, but it needs to be something that doesn't create a heavy cognitive load on the caller. > > 3. Finally, and importantly, there's really already enough information provided in existing proc definitions to unambiguously define a viable new behavior for any proc that currently uses optional positional parameters. > > So, by point 2, let's say we have a flag on the call or any proc: if the proc name is preceded by a "-" and the same proc name with the "dash" included doesn't already exist, then the call will be made with the named parameter syntax: > > Using this example proc: > > proc foo {bar {opt1 ""} {opt2 ""} args} { > > puts [list called foo bar= $bar opt1= $opt1 opt2= $opt2 args= $args] > > } > > This provides enough information for any call using named arguments: > > [foo zot b] -> "called foo bar= zot opt1= b opt2= {} args= {}" > > [-foo zot b] -> "called foo bar= zot opt1= {} opt2= {} args= b" > > [foo zot -opt2 b] -> "called foo bar= zot opt1= -opt2 opt2= b args= {}" > > [-foo zot -opt2 b] -> "called foo bar= zot opt1= {} opt2= b args= {}" > > The use of "-" as a sentinel is not the only possible syntax, of course, but it's one that would be immediately recognizable. One could call "*foo" or "@foo" or even "{-}foo" to make completely sure there's no chance of naming conflict. > > In addition, it would be OK to have something to flag a proc as always taking the new syntax. For example: > > proc -named-parameters foo {bar {opt1 ""} {opt2 ""} args} { ... } > > nproc foo {bar {opt1 ""} {opt2 ""} args} { ... } > > Or even: > > -proc foo {bar {opt1 ""} {opt2 ""} args} { ... } > > Though that may be too "cute". > > Regardless of the exact syntax, a proc defined this way wouldn't even allow positional parameters for arguments with a default value. > > [foo zot b] -> "called foo bar= zot opt1= {} opt2= {} args= b" > > [-foo zot b] -> "called foo bar= zot opt1= {} opt2= {} args= b" > > [foo zot -opt2 b] -> "called foo bar= zot opt1= {} opt2= b args= {}" > > [-foo zot -opt2 b] -> "called foo bar= zot opt1= {} opt2= b args= {}" > > ------------------------------------------------------------------------------> Check out the vibrant tech community on one of the world's most> engaging tech sites, SlashDot.org! http://sdm.link/slashdot [1]> > _______________________________________________> Tcl-Core mailing list> Tcl-...@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/tcl-core [2]
 

Links:
------
[1] http://sdm.link/slashdot
[2] https://lists.sourceforge.net/lists/listinfo/tcl-core
[3] ../tcl-core/16590/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core

Recent Messages in this Thread
Peter da Silva Jan 18, 2017 04:17 pm
Dipl. Ing. Sergey G. Brester Jan 18, 2017 05:20 pm
Peter da Silva Jan 18, 2017 05:32 pm
Dipl. Ing. Sergey G. Brester Jan 18, 2017 06:08 pm
Mathieu Lafon Jan 18, 2017 09:32 pm
Peter da Silva Jan 18, 2017 10:25 pm
Mathieu Lafon Jan 18, 2017 11:07 pm
Dipl. Ing. Sergey G. Brester Jan 18, 2017 11:49 pm
Peter da Silva Jan 18, 2017 11:52 pm
rene Jan 25, 2017 10:15 am
Steve Landers Jan 25, 2017 12:06 pm
Gustaf Neumann Jan 25, 2017 01:50 pm
Peter da Silva Jan 25, 2017 01:55 pm
rene Jan 25, 2017 02:00 pm
Peter da Silva Jan 25, 2017 04:11 pm
Florent Merlet Jan 25, 2017 08:20 pm
Messages in this thread