Quantcast

TIP457 Implementation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

TIP457 Implementation

Mathieu Lafon
Hello,

An initial implementation of TIP457 is available at :

  https://github.com/mlafon/tcl/tree/tip457-named-arg

I can also create a similar branch in fossil if I can get a write access.

I have not yet updated the TIP, but the following modifications have been done :
- Options are specified without additional braces. example : { a
-default 0 -name val -name high -value 9 }
- An [info argspec prog arg] command has been added to get the
argument specification of a proc argument

Feedback welcomed.

-- Mathieu

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Andreas Leitgeb
> An initial implementation of TIP457 is available at :
>   https://github.com/mlafon/tcl/tree/tip457-named-arg
> I can also create a similar branch in fossil if I can get a write access.

I've done this for the meantime, but I'm sure you'll be granted it, if
you sign up (if you haven't already done it) and then let us know your
username.

> I have not yet updated the TIP, but the following modifications have been done :
> - Options are specified without additional braces. example :
>      { a -default 0 -name val -name high -value 9 }

Thanks a lot for this change!

> - An [info argspec prog arg] command has been added to get the
>      argument specification of a proc argument

Yeah, that should address introspection.

> Feedback welcomed.

- There are a warnings about unused local variables (i, localPtr)

- you seem to require a -default for named options with -value.
    This makes sense in the simple case, where only one -name with a
    -value is specified, but may be too strict, if more -name's are
    given. A procedure might want to require at least one of the
    options to be given.  (#wishlist)

- for some reason, it seems like a "--" is currently required, when a
    positional argument follows a named group, even if the following
    argument is not one of the options. (#notsureifintended)

% proc foo {{x -name foo -value foo -name bar -value bar} y} { list $x $y }
-default required for -value
% proc foo {{x -default dflt -name foo -value foo -name bar -value bar} y} { list $x $y }
% foo blarg
wrong # args: should be "foo ?|-x|? y"
% foo -foo blarg
wrong # args: should be "foo ?|-foo|-bar|? y"
% # works with explicit "--"
% foo -foo -- blarg
foo blarg
% foo -- blarg
dflt blarg


And something quite far-fetched: I'm wondering why internal reps in the
arg-spec go amiss. They already did in original proc from trunk, so this
isn't critique on your code.  Otoh., my pure-tcl implementation on wiki
https://wiki.tcl.tk/48569 seems to beat proc in this rare usecase, so
I'll probably look into the C sources to find out where internal reps
get lost - maybe there's a reason for it, afterall.

% proc r [list [list x -default [expr {6*9}] -name x -value [expr {6*7}]]] \
  { tcl::unsupported::representation $x }
% r -x
value is a pure string [...], string representation "42"
% r
value is a pure string [...], string representation "54"

trunk-tclsh:
% proc s [list [list x [expr {6*9}]]] { tcl::unsupported::representation $x }
% s
value is a pure string [...], string representation "54"

pure-tcl from wiki:
% procx s [list [list x [expr {6*9}]]] { tcl::unsupported::representation $x }
% call s
value is a int [...], internal representation [...], no string representation
# ditto for more elaborate name/value cases


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Mathieu Lafon
On Fri, Mar 10, 2017 at 10:47 AM, avl <[hidden email]> wrote:
> I've done this for the meantime, but I'm sure you'll be granted it, if
> you sign up (if you haven't already done it) and then let us know your
> username.

I have commited modifications detailed below on my GitHub repo if you
want to commit them on fossil. My username on core.tcl.tk is mlafon.

> - There are a warnings about unused local variables (i, localPtr)

Fixed.

> - you seem to require a -default for named options with -value.
>     This makes sense in the simple case, where only one -name with a
>     -value is specified, but may be too strict, if more -name's are
>     given. A procedure might want to require at least one of the
>     options to be given.  (#wishlist)

Yes, that make sense to remove this rule. Done.

> - for some reason, it seems like a "--" is currently required, when a
>     positional argument follows a named group, even if the following
>     argument is not one of the options. (#notsureifintended)

This was (initially) intended. But now that all options start with a
dash, we can safely end the named group handling on the first argument
without a leading dash. Done.

-- Mathieu

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Mathieu Lafon
In reply to this post by Mathieu Lafon
TIP 457 has been updated regarding latest discussions. I hope we can
reach a consesus using that version.

  http://www.tcl.tk/cgi-bin/tct/tip/457.html

The implementation is now on a fossil branch and nearly finished. The
main missing part is the update of doc/proc.n

  http://core.tcl.tk/tcl/timeline?r=tip-457

-- Mathieu


On Thu, Mar 9, 2017 at 10:36 PM, Mathieu Lafon <[hidden email]> wrote:

> Hello,
>
> An initial implementation of TIP457 is available at :
>
>   https://github.com/mlafon/tcl/tree/tip457-named-arg
>
> I can also create a similar branch in fossil if I can get a write access.
>
> I have not yet updated the TIP, but the following modifications have been done :
> - Options are specified without additional braces. example : { a
> -default 0 -name val -name high -value 9 }
> - An [info argspec prog arg] command has been added to get the
> argument specification of a proc argument
>
> Feedback 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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Andreas Leitgeb
In reply to this post by Mathieu Lafon
In current state of TIP-457:
% proc foo {{x -upvar xn}} { incr x; list $x $xn }
% foo x
wrong args: pass-by-name variable "x" does not exist
%

I really don't like this *general* restriction to pre-existing
outer variables. That's not how upvar as a command works, and
it disables the feature for usecases where the procedure is meant
to initialize the variable.

Here is an alternative suggestion - a compromise?

 - if a non-empty outer name is given to -upvar, then leave it to the
      proc to deal with "fresh" variables.

 - if the outer name is the empty string, then require a var (or arr)
      to already exist in outer scope at call time.


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Peter da Silva-2
On 2017-03-18, at 07:49, Andreas Leitgeb <[hidden email]> wrote:
> In current state of TIP-457:
> % proc foo {{x -upvar xn}} { incr x; list $x $xn }
> % foo x
> wrong args: pass-by-name variable "x" does not exist
> %

> I really don't like this *general* restriction to pre-existing
> outer variables. That's not how upvar as a command works, and
> it disables the feature for usecases where the procedure is meant
> to initialize the variable.

Good call!

>
> Here is an alternative suggestion - a compromise?
>
> - if a non-empty outer name is given to -upvar, then leave it to the
>      proc to deal with "fresh" variables.
>
> - if the outer name is the empty string, then require a var (or arr)
>      to already exist in outer scope at call time.

Assuming I'm not misunderstanding this, I'm not sure this second requirement is needed. Existing "upvar" allows uninitialized outer variables to be initialized by the inner procedure without the actual code that does the initialization knowing the outer name.

% proc init1 {_a} { upvar 1 $_a a; if {![info exists a]} {set a 1} }
% puts $bloop
can't read "bloop": no such variable
% init1 bloop
1
% puts $bloop
1

In the new scheme this would be:

% proc init1 {{a -upvar _a}} { if {![info exists a]} {set a 1} }
% puts $bloop
can't read "bloop": no such variable
% init1 bloop
1
% puts $bloop
1

But _a isn't actually used. But you seem to be suggesting that if it doesn't provide an outer name, it should require the variable be initialized:

% proc init1 {{a -upvar {}}} { if {![info exists a]} {set a 1} }
% puts $bloop
can't read "bloop": no such variable
% init1 bloop
wrong args: pass-by-name variable "bloop" does not exist

Why should that be an error? This should be perfectly legit:

% proc init1 {{a -upvar {}}} { if {![info exists a]} {set a 1} }
% puts $bloop
can't read "bloop": no such variable
% init1 bloop
1
% puts $bloop
1

And just requiring the variable exists isn't enough to prevent inner proc errors. Consider this:

% proc myincr {{a -upvar _a}} { incr a }
% myincr foo
1
% set bar(a) 1
1
% myincr bar
can't set "a": variable is array
%

So the proc has to perform its own sanity checking or allow unexpected names to propagate outwards, I say leave it up to the user whether they want to provide an outer name variable.
------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Andreas Leitgeb
On Sat, Mar 18, 2017 at 01:42:00PM +0000, Peter da Silva wrote:
> On 2017-03-18, at 07:49, Andreas Leitgeb <[hidden email]> wrote:
> > Here is an alternative suggestion - a compromise?
> > - if a non-empty outer name is given to -upvar, then leave it to the
> >      proc to deal with "fresh" variables.
> > - if the outer name is the empty string, then require a var (or arr)
> >      to already exist in outer scope at call time.
> Assuming I'm not misunderstanding this, I'm not sure this second
> requirement is needed.

I'd just be fine with dropping the existence check for outer variables
altogether.  There was a private discussion between me and Mathieu about
allowing fresh variables for -upvar or not.  Mathieu just judges this
case differently than me.

On this basis, I meant to suggest a compromise between "nanny mode"
where tcl would check the outer variable, and some "advanced mode"
where the procedure has full control while not giving up convenience.

It seemed "ok" (not "necessary") to me to tie this decision to non-
emptiness of the -upvar's outerName.

I think it is not overly burdensome to demand a non-empty outerName
for cases where the proc wants extra flexibility beyond "nanny mode".
In lack of an idea for a proper name, just use "_". :-)


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Peter da Silva-2
On 2017-03-18, at 09:22, avl <[hidden email]> wrote:
> I'd just be fine with dropping the existence check for outer variables
> altogether.  There was a private discussion between me and Mathieu about
> allowing fresh variables for -upvar or not.  Mathieu just judges this
> case differently than me.

I'd be interested in seeing the rationale for having this nanny-mode at all, because all it seems to do is improve the error message from one particular failure mode that the inner code is perfectly capable of handling and often needs to.
------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Mathieu Lafon
On Sat, Mar 18, 2017 at 4:01 PM, Peter da Silva
<[hidden email]> wrote:
> On 2017-03-18, at 09:22, avl <[hidden email]> wrote:
>> I'd just be fine with dropping the existence check for outer variables
>> altogether.  There was a private discussion between me and Mathieu about
>> allowing fresh variables for -upvar or not.  Mathieu just judges this
>> case differently than me.
>
> I'd be interested in seeing the rationale for having this nanny-mode at all, because all
> it seems to do is improve the error message from one particular failure mode that the
> inner code is perfectly capable of handling and often needs to.

After reading the use-case for not requiring the outer variable to
exist, I have removed the check
and updated the tests.

Regards.

-- 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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Kevin Kenny-6
In reply to this post by Mathieu Lafon
Andreas Leitgeb posted a query about the status of TIP #457 on the
Tclers' Chat today. I had not realized that he and Mathieu Lafon had
considered the definition to be stable enough to be close to voting.

I've taken a quick look and the proposal and the implementation on the
'tip-457' branch in the core.tcl.tk repository, and I mostly like what
I see so far. There seems to be considerable regrouping from some of
the earlier discussion, a lot of which was quite strange indeed.

I have a few specific comments that I'd like to see addressed:

(1) The implementation has no test suite. Ideally, I'd like to
    see "white box" tests with 100% or near-100% coverage of the
    modified code, together with "black box" tests illustrating
    both the salient points of the implementation and the common
    error cases. This is not necessarily a barrier to voting on
    the TIP, but must be addressed before the TIP is considered
    FINAL (ideally before the implementation is merged onto the
    trunk).

(2) The implementation has no updates to the documentation. This
    deficiency surely must be addressed before the TIP goes FINAL,
    ideally before the implementation is merged into 'trunk'. Once
    again, this need not be a showstopper for the vote. But with
    that said:

(3) The language of the TIP is a bit confusing. I think I can assist
    with the word-smithing, provided that I first understand it
    fully myself! I appear to be failing to do so, because in the
    implementation on the tip-457 branch, I'm being surprised with
    what I thought was a simple example.

    Goal: Write a trivial procedure that accepts a variable name
    on a mandatory '-var' option, and supports an optional '-incr'
    option that defaults to 1. Increment the given variable by the
    given increment, and report on the standard output that it
    has done so.

    Trial implementation:

    proc x {{v -name var -upvar nm}
            {i -default 1 -name incr}} {
        incr v $i
        puts "$nm was incremented by $i"
        return $v
    }

    Example call:
    x -var a -incr 2

    Result:
    wrong # args: should be "x |-var &v&| ?|-incr i|?"

    As long as I'm getting this level of astonishment, I think there's
    something wrong with the description in the TIP.

(4) I think that the description also needs to be more explicit about the
    dependence of the behaviour on the order of the flags within a
    parameter specifier. I first wrote (incorrectly):

    proc x {{v -name var -upvar nm}
            {i -name incr -default 1}} { ... }

    and was surprised by an error message indicating that -default
    had to come first. I think I understand why this is (there can
    be multiple -name's referring to the same parameter), but it's
    a bit of syntax that I wasn't expecting.

(5) Would it be feasible to implement this for [apply] forms and TclOO
    methods (including constructors) as well as for proc's?  It seems
    inconsistent to have it for only one of the three, and not having
    it in all three contexts would surely make me stumble at some
    point. In fact, I think constructors are perhaps the place that
    would benefit the most from having named arguments.

(6) Is it an error to specify the same parameter redundantly? What
    sort of message is generated for erroneous code like
    [x -incr 2 -var foo -incr 3]?

(7) Is it an error to have a hyphen as the start of a variable name?
    I can imagine that otherwise, there will be some peculiar
    ambiguities:

       proc what {{x -upvar -name -name vv}} { ... }

    (Is this putting the string value of the parameter in ${-name}?
    Or is it an error? Or something else?)

(8) Would the proponents be willing at least to consult with Donal
    and me about approaches to compiling this thing? It would be
    nice if we can figure out how to do it so that all the argument
    analysis for a call like [x -var b -incr 10] could be inlined and
    specialized. I think I see most of how to do it (the auto-upvar
    will maybe be a trifle tricky), but since I may have misunderstood
    the specification, I may need some further help. If the
    proponents are willing, we could take this discussion over to
    the tclquadcode mailing list.

Please don't be discouraged by the long list of questions! I think
that on the whole, this TIP is looking quite promising, otherwise, I'd
not have taken the time to ask them. Let's keep moving forward on
this!


On Thu, Mar 9, 2017 at 4:36 PM, Mathieu Lafon <[hidden email]> wrote:
Hello,

An initial implementation of TIP457 is available at :

  https://github.com/mlafon/tcl/tree/tip457-named-arg

I can also create a similar branch in fossil if I can get a write access.

I have not yet updated the TIP, but the following modifications have been done :
- Options are specified without additional braces. example : { a
-default 0 -name val -name high -value 9 }
- An [info argspec prog arg] command has been added to get the
argument specification of a proc argument

Feedback welcomed.

-- Mathieu

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Kevin Kenny-6
On Mon, Mar 20, 2017 at 3:27 PM, Kevin Kenny <[hidden email]> wrote:
(1) The implementation has no test suite. Ideally, I'd like to
    see "white box" tests with 100% or near-100% coverage of the
    modified code, together with "black box" tests illustrating
    both the salient points of the implementation and the common
    error cases. This is not necessarily a barrier to voting on
    the TIP, but must be addressed before the TIP is considered
    FINAL (ideally before the implementation is merged onto the
    trunk).

Ignore this point. I botched a `fossil diff` invocation. Sorry!

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Andreas Leitgeb
In reply to this post by Kevin Kenny-6
Just a quick clarification beforehand: there was a bit of
misunderstanding.  I merely polled for comments about it,
saying that to me the implementation seemed pretty complete.

I cannot talk for mlafon, whose tip it is.  Only he can decide
about when it is really finished and ready for a CfV.

point (1) has already been refuted on the chat.

Yes, documentation updates are indeed still missing.

so much for a quick reply.  maybe more later.

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Kevin Kenny-6
In reply to this post by Kevin Kenny-6
On Mon, Mar 20, 2017 at 3:27 PM, Kevin Kenny <[hidden email]> wrote:
(5) Would it be feasible to implement this for [apply] forms and TclOO
    methods (including constructors) as well as for proc's?  It seems
    inconsistent to have it for only one of the three, and not having
    it in all three contexts would surely make me stumble at some
    point. In fact, I think constructors are perhaps the place that
    would benefit the most from having named arguments.

Now that I see the test suite, I see that you did [apply] already.
The question is still open with respect to methods.



------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Andreas Leitgeb
In reply to this post by Kevin Kenny-6
On Mon, Mar 20, 2017 at 03:27:22PM -0400, Kevin Kenny wrote:
> (2) The implementation has no updates to the documentation. ...
> (3) The language of the TIP is a bit confusing. ...
>     Example call:
>     x -var a -incr 2
>     Result:
>     wrong # args: should be "x |-var &v&| ?|-incr i|?"

This confuses even me. Thanks for pointing out a bug. :-)

This reproduces it:
% proc x {{v -name v -upvar _} {i -name i}} { }
% x -v x -i 1
wrong # args: should be "x |-v &v&| |-i i|"

This doesn't:
% proc x {{v -name v -upvar {}} {i -name i}} { }
% x -v x -i 1

Mathieu?

> (4) I think that the description also needs to be more explicit
>     about the dependence of the behaviour on the order of the
>     flags within a parameter specifier. ...

Since docs aren't yet done (2), I can only assume you mean the
description in the TIP, but that says about -default:
" When used, it must be specified before any -name option. "
And for those who don't read docs, anyway, the error seems
quite clear to me. ;-)

> (5) Would it be feasible to implement this for [apply] forms

It actually works for apply:
% proc foo {{x -name x} {y -name y}} { list $x $y }
% foo -x 1 -y 2
1 2
% apply {{{x -name x} {y -name y}} { list $x $y }} -x 1 -y 2
1 2

>     and TclOO methods (including constructors) as well

Depending on what C-Api they use, they might already enjoy it.
(My TclOO-fu is too low, to quickly try it)

> (6) Is it an error to specify the same parameter redundantly?
>     sort of message is generated for erroneous code like
>     [x -incr 2 -var foo -incr 3]?

Later options overwrite earlier ones. increment by 3 would result.
Not sure, if Mathieu will change it to an error...

> (7) Is it an error to have a hyphen as the start of a variable name?
>        proc what {{x -upvar -name -name vv}} { ... }

Well, when -name's are present, an -upvar may not be before the
first one. Apart from that, e.g. if you swap the -name and -upvar in
your example, then "-name" is a perfectly legal name for the outerName.

> (8) Would the proponents be willing at least to consult with Donal
>     and me about approaches to compiling this thing? [...]
>     If the proponents are willing, we could take this
>     discussion over to the tclquadcode mailing list.

I'd surely try to assist with my own understanding of the TIP, and
apparently a bit more time at my hands for discussion.  But I think
the quadcode flies pretty high above my head...

PS: Thanks for your interest!

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Mathieu Lafon
In reply to this post by Kevin Kenny-6
Hello Kevin,

On Mon, Mar 20, 2017 at 8:27 PM, Kevin Kenny <[hidden email]> wrote:

> (2) The implementation has no updates to the documentation. This
>     deficiency surely must be addressed before the TIP goes FINAL,
>     ideally before the implementation is merged into 'trunk'. Once
>     again, this need not be a showstopper for the vote. But with
>     that said:

Yes, this is the only missing part for me. I have initially delayed it
a bit until I get enough positive feedback on the current proposal. If
people are positive with it, I will update it soon.

> (3) The language of the TIP is a bit confusing. I think I can assist
>     with the word-smithing, provided that I first understand it
>     fully myself! I appear to be failing to do so, because in the
>     implementation on the tip-457 branch, I'm being surprised with
>     what I thought was a simple example.
>     [...]
>     Example call:
>     x -var a -incr 2
>
>     Result:
>     wrong # args: should be "x |-var &v&| ?|-incr i|?"
>
>     As long as I'm getting this level of astonishment, I think there's
>     something wrong with the description in the TIP.

Doh, that's a bug, shame on me. I have commited a fix on the branch.

> (4) I think that the description also needs to be more explicit about the
>     dependence of the behaviour on the order of the flags within a
>     parameter specifier. I first wrote (incorrectly):
>
>     proc x {{v -name var -upvar nm}
>             {i -name incr -default 1}} { ... }
>
>     and was surprised by an error message indicating that -default
>     had to come first. I think I understand why this is (there can
>     be multiple -name's referring to the same parameter), but it's
>     a bit of syntax that I wasn't expecting.

The order is important especially if there are several -name options.

For example:
  proc p {{v -name val -default 1 -name high -value 9}} {}
... would be confusing because the default value is not related to
'val' but to the 'v' argument.

We can however accept it if there is only one -name specified.

> (5) Would it be feasible to implement this for [apply] forms and TclOO
>     methods (including constructors) as well as for proc's?  It seems
>     inconsistent to have it for only one of the three, and not having
>     it in all three contexts would surely make me stumble at some
>     point. In fact, I think constructors are perhaps the place that
>     would benefit the most from having named arguments.

I have handled both apply and TclOO methods. See oo-36.x testcases in
oo.test. Is there something which was not correctly handled?

> (6) Is it an error to specify the same parameter redundantly? What
>     sort of message is generated for erroneous code like
>     [x -incr 2 -var foo -incr 3]?

No, there is no error, the last specified argument "wins" (incr=3
here). I have no strong opinion on whether this should be refused or
ignored.

> (7) Is it an error to have a hyphen as the start of a variable name?
>     I can imagine that otherwise, there will be some peculiar
>     ambiguities:
>
>        proc what {{x -upvar -name -name vv}} { ... }
>
>     (Is this putting the string value of the parameter in ${-name}?
>     Or is it an error? Or something else?)

There is no error, '-name' is used as the argument name in which to
store the variable outer name.

> (8) Would the proponents be willing at least to consult with Donal
>     and me about approaches to compiling this thing? It would be
>     nice if we can figure out how to do it so that all the argument
>     analysis for a call like [x -var b -incr 10] could be inlined and
>     specialized. I think I see most of how to do it (the auto-upvar
>     will maybe be a trifle tricky), but since I may have misunderstood
>     the specification, I may need some further help. If the
>     proponents are willing, we could take this discussion over to
>     the tclquadcode mailing list.

Yep, I will provide any help needed if I can.

> Please don't be discouraged by the long list of questions! I think
> that on the whole, this TIP is looking quite promising, otherwise, I'd
> not have taken the time to ask them. Let's keep moving forward on
> this!

Thanks for your valuable feedback.

-- 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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Mathieu Lafon
In reply to this post by Andreas Leitgeb
On Mon, Mar 20, 2017 at 8:43 PM, avl <[hidden email]> wrote:
> Just a quick clarification beforehand: there was a bit of
> misunderstanding.  I merely polled for comments about it,
> saying that to me the implementation seemed pretty complete.
>
> I cannot talk for mlafon, whose tip it is.  Only he can decide
> about when it is really finished and ready for a CfV.

The current TIP and it's implementation is in a nearly-finished state
for me, with the proc.n update the only missing point.

I'm unsure if the CFV should be triggered by me or a TCT member but
this is probably the next step if the current proposal receive
positive feedback.

-- 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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Mathieu Lafon
In reply to this post by Andreas Leitgeb
On Mon, Mar 20, 2017 at 9:38 PM, avl <[hidden email]> wrote:
>> (7) Is it an error to have a hyphen as the start of a variable name?
>>        proc what {{x -upvar -name -name vv}} { ... }
>
> Well, when -name's are present, an -upvar may not be before the
> first one. Apart from that, e.g. if you swap the -name and -upvar in
> your example, then "-name" is a perfectly legal name for the outerName.

Yes, well spotted Andreas. In that case, '-upvar -name' must be
specified after '-name vv' as it must relate to the named argument.

-- 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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Stefan Sobernig-2
In reply to this post by Andreas Leitgeb
Hi,

> I cannot talk for mlafon, whose tip it is.  Only he can decide
> about when it is really finished and ready for a CfV.

Just to bring one thing up again (as it became buried in another thread):

> The point is: Optionality does not necessarily build on defaults (both,
> for nonpos and pos parameters).
>
> % nsf::proc foo {a:optional} {
> if {[info exists a]} {
>    set a
> }
> }
>
> % foo; # valid, no default
>
> % foo 1; # valid
> 1
> That is an interesting idea. I like it. It avoids the "magic token"
default problem.
>

and

> But note that optional nonpos parameters do *not* have to take defaults,
> they can but this is facultative (in NSF):
>
> % nsf::proc foo {-a args} {
>       if {[info exists a]} {
>     set a
>       }
>   }

How can this be served by TIP #457? There was some interest in the idea
by Peter and NSF could use it to compile its own parameter specs down to it.

Also, I am wondering whether TclOO & friends would not cry for another
option: -variable (akin to -upvar)?

method foo {{x -name x -variable y}} {;}

as a shortcut for:

method foo {{x -name x}} {
    my variable y
    set y $x
}

This would also help reduce typical constructor boilerplate.

Overall, I am still not convinced by TIP #457 as it stands (conceptually
how positional and name binding are married; see our earlier email; but
also at the syntax level: repeated param names, ordering constraints on
options as list elements). Besides, I haven't heart all too many TCT
voices on it either?

Cheers,
Stefan






--
Institute for Information Systems and New Media
WU Vienna, Austria
Welthandelsplatz 1, Building D2, A-1020 Vienna

[hidden email]
http://nm.wu.ac.at/en/sobernig

t. +43-1-31336-4878
f. +43-1-31336-90-4878

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Andreas Leitgeb
Stefan Sobernig <[hidden email]> wrote:

> Just to bring one thing up again (as it became buried in another thread):
>> The point is: Optionality does not necessarily build on defaults (both,
>> for nonpos and pos parameters).
>> % nsf::proc foo {a:optional} { ... }
>> % foo; # valid, no default
>> That is an interesting idea. I like it. It avoids the "magic token"
>> default problem.
> How can this be served by TIP #457? There was some interest in the idea
> by Peter and NSF could use it to compile its own parameter specs down to
> it.

TIP 457 doesn't address this feature.  I consider it a "nice to have", but
not quite a "must have", so my own urge to find an apt option name by which
to fit it in  is not too strong.

Having options {use -default 0 -name use -value 1} and check
on $use seems more convenient to me, than checking [info exists ...].
Exactly reproducing [set]'s interface just isn't all that common,
and parsing args doesn't magically become impossible, either.

> Also, I am wondering whether TclOO & friends would not cry for another
> option: -variable (akin to -upvar)?

That doesn't make sense to me.  globals and ns-variables are not part
of the proc/method's interface. The "upvar 1 ..."-use is different,
as it links from the caller.

> Overall, I am still not convinced by TIP #457 as it stands (conceptually
> how positional and name binding are married; see our earlier email;
> but also at the syntax level: repeated param names, ordering constraints
> on options as list elements).

I don't see these as problems. Could you point your finger more
precisely on what bothers you?
Unix "ls" accepts -lucucucucucucucucuc - which of c or u is last, counts.

The ordering constraints on the arg spec help save braces and make them
more convenient to use and easier on the eye.

> Besides, I haven't heard all too many TCT voices on it either?

So far kbk is the only one. The tip had a somewhat unlucky start trying
to achieve more than Tcl allows for. Some TCT members might still have
it on their mental "ignore" list. I think, the word will eventually spread.


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: TIP457 Implementation

Steve Landers

On 21 Mar 2017, 9:08 AM +0800, avl <[hidden email]>, wrote:

So far kbk is the only one. The tip had a somewhat unlucky start trying
to achieve more than Tcl allows for. Some TCT members might still have
it on their mental "ignore" list. I think, the word will eventually spread.

The TIP arrived over the holiday period, and initially it appeared “post modern” in that it doesn't reference existing solutions such as NSF or Cyan Olgivie’s paper from Tcl2016. Nor does it address TclOO, apply etc. I’ve already expressed these views on the chat, I’m not sure if they were lost in the noise or just didn’t stick.

This isn’t a criticism, just an observation and to assure you it isn’t on my mental ignore list.

Steve

 

------------------------------------------------------------------------------
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
1234
Loading...