Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
TIP 572 : Not core debate
105 views
Skip to first unread message
Ali M
May 11, 2020, 7:23:54 PM5/11/20
to
tip 571 is suggesting adding a new command to specify a call strategy
for a command call
example from the tip https://core.tcl-lang.org/tips/doc/trunk/tip/572.md
# Specify the call strategy for the command: manipulateData (Only the fifth argument will be passed by value. The other ones will be passed by name)
callstrat manipulateData & & & & * &
#Call the target procedure
manipulateData a b c d $e f
wouldnt it be nicer if this command is implemented more like a control structure
that accept two blocks
for example
callstrat {
manipulateData & & & & * &
} for {
manipulateData a b c d $e f
}
this way the scope of the call strategy will be explicit rather than implicit
and would allow to define multiple strategies for different commands in the same block
please note, its been while since i touched tcl, so i can be completely off
for a command call
example from the tip https://core.tcl-lang.org/tips/doc/trunk/tip/572.md
# Specify the call strategy for the command: manipulateData (Only the fifth argument will be passed by value. The other ones will be passed by name)
callstrat manipulateData & & & & * &
#Call the target procedure
manipulateData a b c d $e f
wouldnt it be nicer if this command is implemented more like a control structure
that accept two blocks
for example
callstrat {
manipulateData & & & & * &
} for {
manipulateData a b c d $e f
}
this way the scope of the call strategy will be explicit rather than implicit
and would allow to define multiple strategies for different commands in the same block
please note, its been while since i touched tcl, so i can be completely off
Christian Gollwitzer
May 12, 2020, 3:28:18 AM5/12/20
to
Am 12.05.20 um 01:23 schrieb Ali M:
discussions that we had previously.
> please note, its been while since i touched tcl, so i can be completely off
>
It is nice that you submitted the TIP with a complete implementation in
C already, that gives good feeling for the performance which can be
achieved. I think the command does not change the basic Tcl semantics
and could also be implemented as a script by renaming the target
procedure to some alias in a namespace and wrapping it with upvar code.
There has been an extensive discussion about named arguments in response
to the Tcl bounties from flightaware
https://github.com/flightaware/Tcl-bounties
They wanted a standard way to parse -option like arguments, and
call-by-reference arguments were part of that discussion. See
http://www.tcl.tk/cgi-bin/tct/tip/457.html for the most complete
implementation. Sadly, the different tastes in the community and the
core team stalled the development.
In my opione, citing from your TIP:
> The important thing in this feature is to preserve the backward compatibility and not to change the procedure definition signature.
I don't like this. I think that it is an advantage to see in the
procedure signature the reference variables, because they are intended
to be modified. In C++ const refs are also used to save copying, for Tcl
with COW that does not play a role. In addition, I don'T like that I
have to count the positional arguments. In your exmaple, when seeing
callstrat & & * &
it's confusing which parameter is modifiable, because the parameter
names are missing. Of course I could add them myself, but then there are
two lines of code which I need to keep in sync, whenever the number or
order of parameters changes.
Best regards,
Christian
> tip 571 is suggesting adding a new command to specify a call strategy
> for a command call
>
> example from the tip https://core.tcl-lang.org/tips/doc/trunk/tip/572.md
>
> # Specify the call strategy for the command: manipulateData (Only the fifth argument will be passed by value. The other ones will be passed by name)
> callstrat manipulateData & & & & * &
>
> #Call the target procedure
> manipulateData a b c d $e f
Thank you for the suggestion. It goes into another direction of
> for a command call
>
> example from the tip https://core.tcl-lang.org/tips/doc/trunk/tip/572.md
>
> # Specify the call strategy for the command: manipulateData (Only the fifth argument will be passed by value. The other ones will be passed by name)
> callstrat manipulateData & & & & * &
>
> #Call the target procedure
> manipulateData a b c d $e f
discussions that we had previously.
> please note, its been while since i touched tcl, so i can be completely off
>
C already, that gives good feeling for the performance which can be
achieved. I think the command does not change the basic Tcl semantics
and could also be implemented as a script by renaming the target
procedure to some alias in a namespace and wrapping it with upvar code.
There has been an extensive discussion about named arguments in response
to the Tcl bounties from flightaware
https://github.com/flightaware/Tcl-bounties
They wanted a standard way to parse -option like arguments, and
call-by-reference arguments were part of that discussion. See
http://www.tcl.tk/cgi-bin/tct/tip/457.html for the most complete
implementation. Sadly, the different tastes in the community and the
core team stalled the development.
In my opione, citing from your TIP:
> The important thing in this feature is to preserve the backward compatibility and not to change the procedure definition signature.
I don't like this. I think that it is an advantage to see in the
procedure signature the reference variables, because they are intended
to be modified. In C++ const refs are also used to save copying, for Tcl
with COW that does not play a role. In addition, I don'T like that I
have to count the positional arguments. In your exmaple, when seeing
callstrat & & * &
it's confusing which parameter is modifiable, because the parameter
names are missing. Of course I could add them myself, but then there are
two lines of code which I need to keep in sync, whenever the number or
order of parameters changes.
Best regards,
Christian
Ali M
May 12, 2020, 8:58:00 AM5/12/20
to
On Tuesday, May 12, 2020 at 3:28:18 AM UTC-4, Christian Gollwitzer wrote:
> Am 12.05.20 um 01:23 schrieb Ali M:
> > tip 571 is suggesting adding a new command to specify a call strategy
> Am 12.05.20 um 01:23 schrieb Ali M:
> > tip 571 is suggesting adding a new command to specify a call strategy
> Thank you for the suggestion. It goes into another direction of
> discussions that we had previously.
>
> > please note, its been while since i touched tcl, so i can be completely off
> >
>
> It is nice that you submitted the TIP
> discussions that we had previously.
>
> > please note, its been while since i touched tcl, so i can be completely off
> >
>
> It is nice that you submitted the TIP
> In my opione, citing from your TIP:
It is very important to clarify, this is not my tip
this tip was submitted by Rami Khaldi, and is discussed on the core-mailing list
Since I am not a member of the tcl-core team, and i dont have knowledge of skills to be one, yet I wanted to discuss this tip, so I mentioned it here in this mailing list, which I think is open to any level of discussion expert to beginner
heinrichmartin
May 12, 2020, 6:40:53 PM5/12/20
to
On Tuesday, May 12, 2020 at 2:58:00 PM UTC+2, Ali M wrote:
> Since I am not a member of the tcl-core team, and i dont have knowledge of skills to be one, yet I wanted to discuss this tip, so I mentioned it here in this mailing list, which I think is open to any level of discussion expert to beginner
I was typing when Christian sent his message. I then stopped because he is more involved than I will ever be, but let me give my 2 cents now.
> Since I am not a member of the tcl-core team, and i dont have knowledge of skills to be one, yet I wanted to discuss this tip, so I mentioned it here in this mailing list, which I think is open to any level of discussion expert to beginner
To me, the TIP seems incomplete ("TODO: create update delete"), inconsistent (e.g. [callstrat apply] does not operate on the args of apply, but on [lindex func 0]; similar for methods), and a wrong approach (a caller should not rely on implementation details).
Your suggestion tackles the open topic life-cycle of the call strategy, but cannot easily solve this for recursive calls either.
Other things that caught my eyes:
* What about dynamic args? (assumingly by-value for two reasons: callstrat defaults to by-value, and binding a variable (in the caller's context) to a list item (of $args) would open more questions than it could answer...)
* callstrat should throw an error instead of silently assuming by-value as a default. Looking at the first character only, asks for hidden bugs.
Like Christian, I would have pointed at TIP-457. It would ease parameters by-reference (see -upvar), but it leaves the decision to the proc, not the caller.
0 new messages