TIP#457 - Add Support for Named Arguments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

TIP#457 - Add Support for Named Arguments

Mathieu Lafon
Hello,

TIP #457 and its implementation have just been updated. The main
modifications are :
- Modification of the behaviour of the -required specifier ;
- Updated implementation in the tip-457 branch, which also include the
updated documentation of info and proc ;
- Updated section on performance.

Related links :
- http://www.tcl.tk/cgi-bin/tct/tip/457.html
- http://core.tcl.tk/tcl/timeline?r=tip-457

As usual, feedback and comments are welcomed.

-- Mathieu

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Alexandre Ferrieux
On Mon, Apr 24, 2017 at 12:58 AM, Mathieu Lafon <[hidden email]> wrote:
>
> TIP #457 and its implementation have just been updated.
> [...]
> As usual, feedback and comments are welcomed.

Thanks for committing all the doc changes.
With this, the nifty fossil-diff to trunk at

 http://core.tcl.tk/tcl/vdiff?from=0ca94b41a13ea375&to=e722c70aad11a12a&sbs=1

gives a very good view of the volume of additions to code, tests, and docs.

Which leads me to the following observation:  this is a big piece
(meaning some code maintenance work) with rich semantics and syntax
(meaning a large extra doc section).
In other words, this departs from the usual "Tcl is a simple language"
rather drastically, by increasing the cognitive entry cost to proc.n.
In addition, this move is done in support of a specific style that's
fashionable in other languages but not really a game-changer in Tcl.
Also, unless I've missed part of the discussion, it is not completely
neutral in terms of perf, as much work on the BC optimizer is still
due before named args can be morphed into positional at compile time.

For this reason, my current position is to vote NO regarding the TIP
itself (meaning core inclusion); but all this work should not be lost
and could very well live in an extension (with the only difference
that input arglist parsing should be explicitly requested by calling a
helper function).

-Alex

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Peter da Silva-2
We consider this a major game changer in Tcl. Positional parameters make maintenance of large Tcl applications dangerously complex, but the verbosity of handcrafting named parameters and the significant overhead for using named parameters in small Tcl functions strongly discourages this idiom.

In addition, I would argue that named parameters and flags are a common and popular style in Tcl itself, but only in built-in commands and in extensions, where they are implemented in C. This change brings Tcl procs into parity with the core of the language.

The original rough design implied by the FlightAware bounty was much simpler, but it was argued that it wasn’t sufficiently Tcl-ish. Would you consider something closer to the original more acceptable?

On 4/23/17, 7:03 PM, "Alexandre Ferrieux" <[hidden email]> wrote:

    On Mon, Apr 24, 2017 at 12:58 AM, Mathieu Lafon <[hidden email]> wrote:
    >
    > TIP #457 and its implementation have just been updated.
    > [...]
    > As usual, feedback and comments are welcomed.
   
    Thanks for committing all the doc changes.
    With this, the nifty fossil-diff to trunk at
   
     http://core.tcl.tk/tcl/vdiff?from=0ca94b41a13ea375&to=e722c70aad11a12a&sbs=1
   
    gives a very good view of the volume of additions to code, tests, and docs.
   
    Which leads me to the following observation:  this is a big piece
    (meaning some code maintenance work) with rich semantics and syntax
    (meaning a large extra doc section).
    In other words, this departs from the usual "Tcl is a simple language"
    rather drastically, by increasing the cognitive entry cost to proc.n.
    In addition, this move is done in support of a specific style that's
    fashionable in other languages but not really a game-changer in Tcl.
    Also, unless I've missed part of the discussion, it is not completely
    neutral in terms of perf, as much work on the BC optimizer is still
    due before named args can be morphed into positional at compile time.
   
    For this reason, my current position is to vote NO regarding the TIP
    itself (meaning core inclusion); but all this work should not be lost
    and could very well live in an extension (with the only difference
    that input arglist parsing should be explicitly requested by calling a
    helper function).
   
    -Alex
   
    ------------------------------------------------------------------------------
    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
    [hidden email]
    https://lists.sourceforge.net/lists/listinfo/tcl-core
   

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Andreas Leitgeb
In reply to this post by Mathieu Lafon
Mathieu Lafon <[hidden email]>
> TIP #457 and its implementation have just been updated. The main
> modifications are :
> - Modification of the behaviour of the -required specifier ;
> - Updated implementation in the tip-457 branch, which also include the
> updated documentation of info and proc ;
> - Updated section on performance.
> As usual, feedback and comments are welcomed.

Two points I'm rather unhappy about in version 1.19 of the TIP:

 *) separation of -upvar <varname> into -upvar <bool> and -varname <varname>

   This one was suggested by kbk. A few days later I asked him on tkchat about
      his motivation. In a nutshell, it was that Kevin didn't like the idea
      of the empty string meaning "I don't care for outer name" and that the
      empty string would not have been a usable <varname> to hold the outer
      variable's name, then.  Given that :: and () are already "characters non
      grata" for formal argument names and that therefore argument names are
      already not "any string"s, then the idea of using the empty string for
      the outer name doesn't seem all that precious to me to make upvar use
      so much more verbose.

   It may be inopportune to criticize kbk's ideas (with all his other contri-
      butions being as awesome as they are), but here that's exactly what I
      feel like doing.

   I wish that this matter caught more attention. If all others decide to go
      with kbk on this point, then obviously I'm going to have to live with it...

 *) -required <bool> (with this option's default depending on namedness of
   options).
   
   Apart from that I principally dislike having formal arguments being
   initially unset, I even more dislike, that for named arguments this
   would even be the default behaviour unless "-required 1" is explicitly
   spelled out.

   I do understand the usecase of some "out-of-band" state for unspecified
   optional arguments (e.g. lsort -command) and suggested an approach with
   "-list" to address this not-quite-that-common usecase.

   But even if unsetting optional arguments (that aren't passed a value) is so
   much preferred, the requiredness behaviour should at least be same for all
   types of parameters, and it should be named for what it means: something
   along -defaultunset <bool>. It's about what happens to unspecified params,
   not about actual requiredness, because for the latter the -default option
   also plays a role.

Well, agree or disagree, that's my feedback, just as asked for. :-)


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Kevin Kenny-6
On Mon, Apr 24, 2017 at 12:56 PM, Andreas Leitgeb <[hidden email]> wrote:
*) separation of -upvar <varname> into -upvar <bool> and -varname <varname>

   This one was suggested by kbk. A few days later I asked him on tkchat about
      his motivation. In a nutshell, it was that Kevin didn't like the idea
      of the empty string meaning "I don't care for outer name" and that the
      empty string would not have been a usable <varname> to hold the outer
      variable's name, then.  Given that :: and () are already "characters non
      grata" for formal argument names and that therefore argument names are
      already not "any string"s, then the idea of using the empty string for
      the outer name doesn't seem all that precious to me to make upvar use
      so much more verbose.

   It may be inopportune to criticize kbk's ideas (with all his other contri-
      butions being as awesome as they are), but here that's exactly what I
      feel like doing.

I didn't worry that much about the verbosity, because it struck me that
actually wanting the name was the exceptional case. I surely
understand that we should not have information that cannot be
introspected, but had trouble seeing an actual use case for
-varname.

I'm by no means always right, and to the extent that my contributions
are 'awesome' (I'd consider simply 'workmanlike' to be high praise)
they got that way by the input of the whole community. 

I'm not wedded
to this, either way. Since we already forbid {} as the name of a procedure
argument (for reasons unknown), I suppose that it's acceptable to
forbid it for a -varname as well.
 
  *) -required <bool> (with this option's default depending on namedness of
   options).

   Apart from that I principally dislike having formal arguments being
   initially unset, I even more dislike, that for named arguments this
   would even be the default behaviour unless "-required 1" is explicitly
   spelled out.

   I do understand the usecase of some "out-of-band" state for unspecified
   optional arguments (e.g. lsort -command) and suggested an approach with
   "-list" to address this not-quite-that-common usecase.

   But even if unsetting optional arguments (that aren't passed a value) is so
   much preferred, the requiredness behaviour should at least be same for all
   types of parameters, and it should be named for what it means: something
   along -defaultunset <bool>. It's about what happens to unspecified params,
   not about actual requiredness, because for the latter the -default option
   also plays a role.

I appreciate that sentiment - uniformity is a Very Good Thing to
have in interfaces. Sometimes, to my way of thinking,
having sensible defaults trumps uniformity. Positional parameters
cannot be optional, except for some contiguous block of them,
without introducing ambiguity. By contrast, named parameters
are optional more often than not:. Look at the profusion of -flags
anywhere in Tk, or the growth of -options on [lsearch] or [regexp]
or anything with a programming interface that's at all complicated.
It strikes me as a bit odd that such options would be required
by default. It's not an uncommon use case at all. It's the usual
situation for most commands I've seen that accept named args.



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Andreas Leitgeb
In reply to this post by Alexandre Ferrieux
Alexandre Ferrieux <[hidden email]> wrote:

> On Mon, Apr 24, 2017 at 12:58 AM, Mathieu Lafon <[hidden email]> wrote:
> > TIP #457 and its implementation have just been updated.
> Thanks for committing all the doc changes.
> With this, the nifty fossil-diff to trunk at
>  http://core.tcl.tk/tcl/vdiff?from=0ca94b41a13ea375&to=e722c70aad11a12a&sbs=1
> gives a very good view of the volume of additions to code, tests, and docs.
>
> Which leads me to the following observation:  this is a big piece
> (meaning some code maintenance work) with rich semantics and syntax
> (meaning a large extra doc section).
> In other words, this departs from the usual "Tcl is a simple language"
> rather drastically, by increasing the cognitive entry cost to proc.n.

Despite the two points in my previous mail that kind of spoil it for
me almost to the point of rather not having it at all, I don't think
that the complexity as such should be the blocker.

Also, I think that the new proc.n is well structured, leaving the simple
old syntax to the front (with just some "teasers" for the fancy stuff),
and the fancy new stuff in its own section.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Kevin Kenny-6
In reply to this post by Alexandre Ferrieux
On Sun, Apr 23, 2017 at 8:03 PM, Alexandre Ferrieux <[hidden email]> wrote:
On Mon, Apr 24, 2017 at 12:58 AM, Mathieu Lafon <[hidden email]> wrote:
>
> TIP #457 and its implementation have just been updated.
> [...]
> As usual, feedback and comments are welcomed.

Thanks for committing all the doc changes.
With this, the nifty fossil-diff to trunk at

 http://core.tcl.tk/tcl/vdiff?from=0ca94b41a13ea375&to=e722c70aad11a12a&sbs=1

gives a very good view of the volume of additions to code, tests, and docs.

Which leads me to the following observation:  this is a big piece
(meaning some code maintenance work) with rich semantics and syntax
(meaning a large extra doc section).
In other words, this departs from the usual "Tcl is a simple language"
rather drastically, by increasing the cognitive entry cost to proc.n.
In addition, this move is done in support of a specific style that's
fashionable in other languages but not really a game-changer in Tcl.
Also, unless I've missed part of the discussion, it is not completely
neutral in terms of perf, as much work on the BC optimizer is still
due before named args can be morphed into positional at compile time.

For this reason, my current position is to vote NO regarding the TIP
itself (meaning core inclusion); but all this work should not be lost
and could very well live in an extension (with the only difference
that input arglist parsing should be explicitly requested by calling a
helper function).

If we bundle this with the core as an extension, it will either become
popular or it will not.

To the extent that it becomes popular, being able to deal with it will become
part of what is required to have a competent reading knowledge of Tcl.

To the extent that it does not become popular, it will have failed to supply
people with much-requested functionality, because it will become much
harder to support when packaging to run in strange places.

The simple, performant interface to [proc] will still be there, and we can
draft the manual page, if necessary, to discuss that first.

I don't think that the bytecoding is a showstopper. For an initial implementation,
as long as we have enough compile-time machinery to get all the variables
that represent positional parameters into the LVT (this doesn't look impossible;
I think I can sign up to do it if the TIP passes), we can get decent, if not
ideal, performance by adding a single bytecode instruction that unpacks
objc/objv into the local variables, taking some representation of the
argument specifications as aux data.

If we can get that far, we're up to "at least the new way is representable
in bytecode, and the old way is still performant." We can proceed at
greater leisure from there; I'm comfortable with having named parameters
be, for a while, only a little faster than interpreted code. To me, the
biggest benefit is that we will have introduced a uniform way to implement
them, rather than a large number of ad hoc hacks that programmers have
introduced over the last couple of decades. It's the number and
quirkiness of the implementations that tends to convince me that this
really needs to be, if not "Core" functionality, at the very least a bundled
extension that can be depended on to be universally available. Since
we have no mechanisms for bundled extensions to do their own BCC,
it really needs to be Core unless that problem is addressed as well.

If you can't bring yourself to support it, or stand aside, I'll just have to hope
that fewer than a third of our colleagues agree with you.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Andreas Leitgeb
In reply to this post by Kevin Kenny-6
On Mon, Apr 24, 2017 at 01:32:06PM -0400, Kevin Kenny wrote:
> On Mon, Apr 24, 2017 at 12:56 PM, Andreas Leitgeb <[hidden email]> wrote:
> > *) separation of -upvar <varname> into -upvar <bool> and -varname <varname>
> >       [...] Given that :: and () are already "characters non grata" for
> >       formal argument names and that therefore argument names are already
> >       not "any string"s, then the idea of using the empty string for the
> >       outer name doesn't seem all that precious to me to make upvar use
> >       so much more verbose.

> I didn't worry that much about the verbosity, because it struck me that
> actually wanting the name was the exceptional case. I surely
> understand that we should not have information that cannot be
> introspected, but had trouble seeing an actual use case for
> -varname.

Suppose a procedure with some "incr"-like behaviour, then if the supplied
variable contained a non-numeric argument, then it would be useful if
the procedure could mention the outer name in its error-message.

So, I think any procedure that isn't entirely tolerant about what the
link points to (even if array or scalar) ought to know the outer name
and produce an error for the outer name, rather than for its local name.

> I'm not wedded
> to this, either way. Since we already forbid {} as the name of a procedure
> argument (for reasons unknown), I suppose that it's acceptable to
> forbid it for a -varname as well.

My intention here is to get rid of the -varname option altogether and
thereby simplify the TIP a bit -- unless there is any prospect of another
use for -varname apart from -upvar.

> >   *) -required <bool> (with this option's default depending on namedness of
> >    options).
> I appreciate that sentiment - uniformity is a Very Good Thing to
> have in interfaces. Sometimes, to my way of thinking, having sensible
> defaults trumps uniformity.

I do understand the power of sensible defaults over uniformity, but
I don't think, that this is such a case.

If one wants to add "yet another option" (and actually *use* it),
then at some point they'd have to write:
  if {[info exists optvar]} { ... }

My point is, that having them just add a numeric default and value to
the arg-spec and then write:
  if {$optvar} { ... }
is the Right'er Thing(tm).

And serendipitously it makes the whole thing easier to describe.


PS: in my own "procx" I've added (after a suggestion on the chat) a
  -boolean {id identifier ...} argspec option, that will implicitly
  set the default to 0 and the value for any of the given identifiers
  (name-aliases) to 1.  -- it complains at proc declaration time if
  it is used together with an explicit -default and a value ne "0".

> Positional parameters
> cannot be optional, except for some contiguous block of them,
> without introducing ambiguity.

That's something that I believe to have disproven in my procx, too.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Peter da Silva-2
On 4/24/17, 1:39 PM, "Andreas Leitgeb" <[hidden email]> wrote:
> If one wants to add "yet another option" (and actually *use* it), then at some point they'd have to write:
>    if {[info exists optvar]} { ... }
   
> My point is, that having them just add a numeric default and value to the arg-spec and then write:
>    if {$optvar} { ... }
> is the Right'er Thing(tm).

Unless 0 is a valid value for optvar. Sometimes you have an optional value that has no special value you can use as a sentinel. Also known as the “how do you store arbitrary binary data in null-terminated strings” problem.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Alexandre Ferrieux
In reply to this post by Kevin Kenny-6
On Mon, Apr 24, 2017 at 7:46 PM, Kevin Kenny <[hidden email]> wrote:

> On Sun, Apr 23, 2017 at 8:03 PM, Alexandre Ferrieux
> <[hidden email]> wrote:
>>
>> On Mon, Apr 24, 2017 at 12:58 AM, Mathieu Lafon <[hidden email]> wrote:
>> >
>> > TIP #457 and its implementation have just been updated.
>> > [...]
>> > As usual, feedback and comments are welcomed.
>>
>> Thanks for committing all the doc changes.
>> With this, the nifty fossil-diff to trunk at
>>
>>
>> http://core.tcl.tk/tcl/vdiff?from=0ca94b41a13ea375&to=e722c70aad11a12a&sbs=1
>>
>> gives a very good view of the volume of additions to code, tests, and
>> docs.
>>
>> Which leads me to the following observation:  this is a big piece
>> (meaning some code maintenance work) with rich semantics and syntax
>> (meaning a large extra doc section).
>> In other words, this departs from the usual "Tcl is a simple language"
>> rather drastically, by increasing the cognitive entry cost to proc.n.
>> In addition, this move is done in support of a specific style that's
>> fashionable in other languages but not really a game-changer in Tcl.
>> Also, unless I've missed part of the discussion, it is not completely
>> neutral in terms of perf, as much work on the BC optimizer is still
>> due before named args can be morphed into positional at compile time.
>>
>> For this reason, my current position is to vote NO regarding the TIP
>> itself (meaning core inclusion); but all this work should not be lost
>> and could very well live in an extension (with the only difference
>> that input arglist parsing should be explicitly requested by calling a
>> helper function).
>
>
> If we bundle this with the core as an extension, it will either become
> popular or it will not.
>
> To the extent that it becomes popular, being able to deal with it will
> become
> part of what is required to have a competent reading knowledge of Tcl.
>
> To the extent that it does not become popular, it will have failed to supply
> people with much-requested functionality, because it will become much
> harder to support when packaging to run in strange places.
>
> The simple, performant interface to [proc] will still be there, and we can
> draft the manual page, if necessary, to discuss that first.
>
> I don't think that the bytecoding is a showstopper. For an initial
> implementation,
> as long as we have enough compile-time machinery to get all the variables
> that represent positional parameters into the LVT (this doesn't look
> impossible;
> I think I can sign up to do it if the TIP passes), we can get decent, if not
> ideal, performance by adding a single bytecode instruction that unpacks
> objc/objv into the local variables, taking some representation of the
> argument specifications as aux data.
>
> If we can get that far, we're up to "at least the new way is representable
> in bytecode, and the old way is still performant." We can proceed at
> greater leisure from there; I'm comfortable with having named parameters
> be, for a while, only a little faster than interpreted code. To me, the
> biggest benefit is that we will have introduced a uniform way to implement
> them, rather than a large number of ad hoc hacks that programmers have
> introduced over the last couple of decades. It's the number and
> quirkiness of the implementations that tends to convince me that this
> really needs to be, if not "Core" functionality, at the very least a bundled
> extension that can be depended on to be universally available. Since
> we have no mechanisms for bundled extensions to do their own BCC,
> it really needs to be Core unless that problem is addressed as well.

You're convincingly outlining a way of driving an unwinking effort to
make it fast, assuming it (the feature itself, not the speed) is worth
it. I seriously am unsure about the latter.

> If you can't bring yourself to support it, or stand aside, I'll just have to
> hope that fewer than a third of our colleagues agree with you.

The key is "Tcl is a small language".  Think about stuff like
Tcl-in-JS. Today's procs can reasonably be transliterated to JS
functions on the fly, due to the similarity of styles (positional +
dynamically typed). Named args make this harder. Moreover, the
extended argspec syntax completely departs from the usual "no-brainer"
left-to-right mapping. This means lowering readability (meaning the
speed at which human eyeballs scan and validate a proc signature).
Yeah you may tag me as too old for innovation, factor of inertia, etc.
But I'd rather see efforts aimed at letting Tcl live on in an
all-superfast-JS era than for the sake of a specific idiom supporting
a very specific workload (behemoth applications with ubiquitous option
processing that for some reason cannot be done with "proc f args
{helper $args;...}"). Last, the Two Thirds rule makes it perfectly
reasonable for the TIP to pass despite my concern if I'm wrong alone,
so I'm not really stabbing anything in the back. That's why I'm
respectfully suggesting that we agree to disagree.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Andreas Leitgeb
In reply to this post by Peter da Silva-2
On Mon, Apr 24, 2017 at 06:53:29PM +0000, Peter da Silva wrote:

> On 4/24/17, 1:39 PM, "Andreas Leitgeb" <[hidden email]> wrote:
>> If one wants to add "yet another option" (and actually *use* it),
>> then at some point they'd have to write:
>>    if {[info exists optvar]} { ... }
>> My point is, that having them just add a numeric default and value to
>> the arg-spec and then write:
>>    if {$optvar} { ... }
>> is the Right'er Thing(tm).
> Unless 0 is a valid value for optvar. Sometimes you have an optional
> value that has no special value you can use as a sentinel.

Yes, we all know the [lsort -command ...] example.
It's just not all that common.


PS: with my procx I could do it this way:
  procx lsort {{cmd {} -l 1 -n command -fv {xx {extra 1} yy {extra 2}}} list} {
     ...
     if {[llength $cmd]==1} {
        # a -command has been given, namely: [lindex $cmd 0] because
        # the -list 1 wraps the argument in a list, but not the default
        # value or values associated to flags with -flagvals option.
     } else { ... }
     ...
  }
  lsort -xx {foo bar}
  lsort -yy {foo bar}
  lsort {foo bar}
  lsort -command {string compare} {foo bar}


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Peter da Silva-2
On 4/24/17, 4:19 PM, "Andreas Leitgeb" <[hidden email]> wrote:
> It's just not all that common.

It’s common enough that I’ve been occasionally annoyed by the lack of a way to distinguish unambiguously between a missing argument and an argument that matches the sentinel with the existing proc positional/default semantics.

And the “info exists” idiom is natural in Tcl. I use it all over the place, even (especially) in this case:

proc init {args} {
    array set opts $args; # I know this is slack as anything but we don’t have TIP457 yet...

    variable build_root

# ...

    if {[info exists opts(-dir)]} {
      set build_root $opts(-dir)
    }

# ...

    if {[info exists opts(-mode)]} {
        catch {exec chmod $opts(-mode) $build_root}
    }

# ... etc etc etc


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Andreas Leitgeb
On Mon, Apr 24, 2017 at 10:11:30PM +0000, Peter da Silva wrote:
> On 4/24/17, 4:19 PM, "Andreas Leitgeb" <[hidden email]> wrote:
> > It's just not all that common.
> It’s common enough that I’ve been occasionally annoyed by the
> lack of a way to distinguish unambiguously between a missing
> argument and an argument that matches the sentinel with the
> existing proc positional/default semantics.

I said: "not all that common", not: "doesn't exist".

The examples you gave (-dir, -mode) both look pretty much like as if the
empty string would be a fine default not getting in the way of useful values.
Even for lsort, an empty -command could have been singled out as a default
that would be equivalent to not specifying a -command option. I wouldn't call
  foreach i {a b c d e f g} {
     proc $i x {puts [info level 0]; string compare {*}[info level 0] }
  }; lsort -command {} {g f e d c b a}
a worthy usecase for an empty command.

The only real undefaultable case presented so far in the whole discussion
is [set]'s second argument.

PS: if you shared two or three of your *really undefaultable* optional
params, that you come across occasionally, it might even make me shut up
about their marginality.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Peter da Silva-2
On 4/24/17, 6:19 PM, "Andreas Leitgeb" <[hidden email]> wrote:
> The examples you gave (-dir, -mode) both look pretty much like as if the empty string would be a fine default not getting in the way of useful values.

You wrote:

>> My point is, that having them just add a numeric default and value to
>> the arg-spec and then write:
>>     if {$optvar} { ... }
>> is the Right'er Thing(tm).

That _only_ works if you can use zero as a sentinel.

The examples I gave all require an explicit test against the sentinel, which is just as verbose as “[info exists...]”, and “[info exists...]” does a better job of self-documenting that you are explicitly testing whether the argument has been provided.

But OK, here’s a more straightforward class of keyword arguments where any value is legal and the presence or absence of the option makes a difference. Any filter-style option in a proc that performs a search or comparison against a value that may be empty. Not comparing against the value is not the same as looking for empty fields. For examples: -name, -school, -flight-id, -registration, -ident, -email, -city, -title, ...

This kind of thing is super common, and workarounds are clumsy.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Donald G Porter-2
In reply to this post by Kevin Kenny-6
On 04/24/2017 01:46 PM, Kevin Kenny wrote:
> The simple, performant interface to [proc] will still be there, and we can
> draft the manual page, if necessary, to discuss that first.

Just on this point, you can take a look at how [return] documentation
was restructured when it grew several complicating options.

--
| Don Porter            Applied and Computational Mathematics Division |
| [hidden email]             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Colin McCormack-3
Not sure what I am missing here, but I tend to use args as dicts to extract named arguments.  Obviously arrays would work as well.  One benefit is no pesky leading dashes.  I understand that this approach precludes singleton flags whose mere presence signifies something.  My response would be "then don't do that."  It's not like my opinion counts especially, but as a long-time tcl programmer, I haven't felt the need for named arguments beyond what can be rolled out of what's already there, and speaking personally I would be loathe to see simple command invocation slowed even an iota for a facility which (although reportedly clamoured for, although in who knows what closed rooms) seems to me to have little actual benefit.

On Tue, 25 Apr 2017, 22:59 Donald G Porter <[hidden email]> wrote:
On 04/24/2017 01:46 PM, Kevin Kenny wrote:
> The simple, performant interface to [proc] will still be there, and we can
> draft the manual page, if necessary, to discuss that first.

Just on this point, you can take a look at how [return] documentation
was restructured when it grew several complicating options.

--
| Don Porter            Applied and Computational Mathematics Division |
| [hidden email]             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Donal K. Fellows-2
On 25/04/2017 17:11, Colin McCormack wrote:
> reportedly clamoured for, although in who knows what closed rooms

The conference room in the hotel in Houston was closed, IIRC, but just
to prevent draughts. :-)

I'm definitely in several minds about this whole area. I really don't
want to see command invocation slowed down, as it is one of the real hot
spots in many people's Tcl code; I'm mindful of the people who are not
complaining. I'm also concerned about the longer-term pickle that you
can get yourself into with named arguments (I've seen a lot of really
messy Python over the past 6 months or so). On the other hand, it'd also
be nice to make it easier for people to do these styles of call, since
we would provide one mechanism that does its task rapidly. Though that
really does need to be opt-in; programmers who wish to take advantage
really need to modify their code to do so, as we don't have the luxury
of being able to say “we break your code for our convenience” very often.

However, the TIP as it stands is much better than its initial version.
(Only the “-switch”-related options seem odd to me. Not bad, just odd.)
I particularly like that this is functionality that people will need to
“buy into” so it won't surprise anyone's existing codebase. The only
confusing thing is the interaction with the “args” magic; the conditions
under which “--” is supported should be more explicitly described. Also,
I assume that it is the intention that lambda terms and TclOO methods
(plus perhaps also methods in other object systems) will support the
same sorts of argument handling? It'd be worth also calling that out.

Donal.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

donal_k_fellows.vcf (241 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Mathieu Lafon
Hello,

On Tue, Apr 25, 2017 at 8:46 PM, Donal K. Fellows
<[hidden email]> wrote:
> I'm definitely in several minds about this whole area. I really don't want
> to see command invocation slowed down, as it is one of the real hot spots in
> many people's Tcl code;

Perhaps the performance section in the TIP has confused readers but
there is really *no* performance issue :

- existing code (and code not using extended argspec) is not impacted
by the change, the current initialisation code is still available and
used ;
- code using extended argspec *may* be impacted because we're using a
different code path which loop on each argument and may handle named
arguments but initial testing does not show a significant slowdown.

On Tue, Apr 25, 2017 at 6:11 PM, Colin McCormack <[hidden email]> wrote:
> Not sure what I am missing here, but I tend to use args as dicts to extract
> named arguments. [...], and speaking personally I would be loathe to see simple
> command invocation slowed even an iota for a facility which (although reportedly
> clamoured for, although in who knows what closed rooms) seems to me to have
> little actual benefit.

On the other side, performance testing has showed that named argument using
tip-457 is 8 time faster than doing it in Tcl-pure code (using a dict
built from 'args').

On Tue, Apr 25, 2017 at 8:46 PM, Donal K. Fellows
<[hidden email]> wrote:
> [...]. Also, I assume that
> it is the intention that lambda terms and TclOO methods (plus perhaps also
> methods in other object systems) will support the same sorts of argument
> handling? It'd be worth also calling that out.

Yes, lambda and TclOO methods/constructor are handled. There are related
subcommands for 'info argspec' (mentionned in TIP) and dedicated tests in
tip-457 branch. I will made it more clear in TIP if that's your point.

-- Mathieu

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Mathieu Lafon
In reply to this post by Andreas Leitgeb
On Mon, Apr 24, 2017 at 6:56 PM, Andreas Leitgeb <[hidden email]> wrote:

> Two points I'm rather unhappy about in version 1.19 of the TIP:
>
>  *) separation of -upvar <varname> into -upvar <bool> and -varname <varname>
>  [...]
>  *) -required <bool> (with this option's default depending on namedness of
>    options).
>  [...]

Thanks for your feedback. I understand your points Andreas but
whatever choice is chosen, someone will be unhappy with it. Of course,
this can still change if there is a large consensus on a different
solution.

In the current solution, I don't see why using '-upvar 1 -varname var'
instead of '-upvar var' and '-name foo -required 1' instead of '-name
foo' is a major problem.

-- Mathieu

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|

Re: TIP#457 - Add Support for Named Arguments

Andreas Leitgeb
On Tue, Apr 25, 2017 at 09:44:20PM +0200, Mathieu Lafon wrote:

> On Mon, Apr 24, 2017 at 6:56 PM, Andreas Leitgeb <[hidden email]> wrote:
> > Two points I'm rather unhappy about in version 1.19 of the TIP:
> >  *) separation of -upvar <varname> into -upvar <bool> and -varname <varname>
> >  [...]
> >  *) -required <bool> (with this option's default depending on namedness of
> >    options).
> >  [...]
> Thanks for your feedback. I understand your points Andreas but
> whatever choice is chosen, someone will be unhappy with it.
> In the current solution, I don't see why using '-upvar 1 -varname var'
> instead of '-upvar var' ... [is a major problem]

The principle here is to make the Right Thing(tm) the easier (or at
least almost equally easy) option.

The Right Thing(tm) here would be procedures that complain about the
outer name of a variable that they're not happy with, rather than about
the internal name.

The likeliness, that someone will capture the outer name with -upvar vname
option (instead of using -upvar {}) and then use it in an error message is
just ways higher, than if they need to type out -upvar 1 -varname vname.

> [and why] '-name foo -required 1' instead of '-name foo' is a major problem.

Meanwhile Peter has provided one usecase (namely specifying filters) for
undefaultable options.

I also have to agree with Kevin, that for named arguments, not needing to
specify them on call site is indeed the much more common case, so breaking
the uniformity is indeed justified.

I still dislike unset formal params, but I have to admit it seems to be
the most general thing to do, where no explicit -default is provided.
In particular, it avoids an arbitrary choice of a "default default".


Nutshell: case -upvar still pending, case -required dropped. :-}

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
123