Menu
▾
▴
#4083 inconsistant "wrong # args" messages
Currently, there is inconsistance here:
>tclsh8.4
% proc foo {a b c args} something
% foo x
wrong # args: should be "foo a b c args"
>tclsh8.5
% proc foo {a b c args} something
% foo x
wrong # args: should be "foo a b c ..."
% interp alias
wrong # args: should be "interp alias slavePath slaveCmd ?masterPath
masterCmd? ?args ..?"
% dict
wrong # args: should be "dict subcommand ?argument ...?"
%
Before starting effort to streamline this, what is the prefered version? Please
vote for one of the following:
A: wrong # args: should be "foo a b c args" (8.4 proc variant)
B: wrong # args: should be "foo a b c ..." (8.5 proc variant)
C: wrong # args: should be "foo a b c ?args ...?" (interp alias variant)
D: wrong # args: should be "foo a b c ?argument ...?" (dict variant)
E: wrong # args: should be "foo a b c ? ...?" (just for completeness)
There are some corner cases, like:
% dict create x
wrong # args: should be "dict create ?key value ...?"
At first sight, my preference would be B, but looking at the "dict create"
example, then C might be more logical: The question mark denotes that
the remaining arguments are optional, between it is some hint
what is expected ('args' already has a special meaning in Tcl), and the
dots signify that the arguments before it can be repeated at will.
Any other ideas?
Regards,
Jan Nijtmans
================================================
This all IMHO...
On Thu, 10 Jul 2008, Jan Nijtmans wrote:
Before starting effort to streamline this, what is the prefered version? Please
vote for one of the following:
A: wrong # args: should be "foo a b c args" (8.4 proc variant)
This could imply to someone not familiar with 'args', or not knowing it's a proc and not a command, that a fourth argument is required. Without the elipsis you don't know (unless you know it's a proc) that foo can take more than 4 arguments, though it's safe guess.
B: wrong # args: should be "foo a b c ..." (8.5 proc variant)
This to me implies "one or more c's", which isn't generally correct because 'args' doesn't imply it's limited to c's.
C: wrong # args: should be "foo a b c ?args ...?" (interp alias variant)
This to me implies "zero or more lists of arg", which isn't correct because all the optional arguments are in a single list.
D: wrong # args: should be "foo a b c ?argument ...?" (dict variant)
This to me implies "zero or more additional arguments", which is the most correct, but I'd go with 'arg' instead as the singular form of 'arg'.
E: wrong # args: should be "foo a b c ? ...?" (just for completeness)
This to me implies "zero or more somethings", which is okay since 'args' is amibguous as to what's expected (just zero or more somethings), but '?arg ...?' points to the fact that its a proc with an 'args' variable.
[nitpicky: space on both sides or neither, not one side.]
There are some corner cases, like:
% dict create x
wrong # args: should be "dict create ?key value ...?"
This form is appropriate when there are more specific requirements for the optional arguments that can be reflected in the usage. In this case, it says you can specify additional arguments, but there must be a multiple of two and each pair is a key and a value.
It's not really a corner case so much as a more specific case. Consider a something slightly different from B:
wrong # args: should be "foo a b ?c ...?"
In contrast with B, this says it must be zero or more c's (but only c's can follow at the end). That would be more specific than "foo a b ?arg ...?" because "arg" is non-specific, but you can't get that "?c ...?" form automatically with a proc.
So, IMHO, this would be most correct and specific for procs:
% proc foo {a b c args} something
% foo x
wrong # args: should be "foo a b c ?arg ...?"
For commands, it depends entirely on what forms the optional arguments can take and in what order.
--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/
=====================================================
Jan Nijtmans wrote:
Before starting effort to streamline this, what is the prefered version? Please
vote for one of the following:
A: wrong # args: should be "foo a b c args" (8.4 proc variant)
B: wrong # args: should be "foo a b c ..." (8.5 proc variant)
C: wrong # args: should be "foo a b c ?args ...?" (interp alias variant)
D: wrong # args: should be "foo a b c ?argument ...?" (dict variant)
E: wrong # args: should be "foo a b c ? ...?" (just for completeness)
I'd agree with what Michael Kirkham wrote: D, but with arg.
Any other ideas?
Whatever is chosen, the choice should be documented -- if not in a manpage, then on the wiki or in a TIP -- since script writers also need to know the recommended style for this occationally (e.g. when coding procs that do further syntax checks on an args argument and want to throw nice-looking error messages).
A related matter is that of distinguishing between formal and actual arguments, i.e., between names of arguments (a b c args above) and values actually supplied by the user. In A-E above only the foo falls in this category, but it can be much more:
% namespace ensemble configure
wrong # args: should be "namespace ensemble configure cmdname ?opt? ?value? ..."
Here namespace, ensemble, and configure are actual arguments, whereas cmdname, opt, and value are formal arguments. This distinction could perhaps be shown somehow.
Also, at the risk of drawing negative attention: I encountered this problem when writing the reference implementation of TIP#314 -- see the last but one section "Notes" in that TIP. Ensembles play some tricks to preserve actual arguments, and I tried to follow the pattern already established.
Lars Hellström
Jan Nijtmans wrote:
Currently, there is inconsistance here:
That was an explicit change, and brought the "wrong # args" generation of procedures into the same framework as the rest of Tcl. In turn, that makes ensemblified commands produce more useful error messages. As part of the process I altered the rendering of error messages produced by procedures so that they appear more useful for normal users, so optional arguments are surrounded by ?'s and args was replaced by an ellipsis, which gives a reasonably nice visual effect.
I didn't go through and audit everything for perfect consistency. No time. So there. :-)
Before starting effort to streamline this, what is the prefered version? Please
vote for one of the following:
A: wrong # args: should be "foo a b c args" (8.4 proc variant)
B: wrong # args: should be "foo a b c ..." (8.5 proc variant)
C: wrong # args: should be "foo a b c ?args ...?" (interp alias variant)
D: wrong # args: should be "foo a b c ?argument ...?" (dict variant)
E: wrong # args: should be "foo a b c ? ...?" (just for completeness)
My preference is "not A", and fix the [dict] inconsistency (so "not D" too). Apart from that, I'm happy to just watch what others prefer.
Donal.
Lars Hellström wrote:
Whatever is chosen, the choice should be documented -- if not in a manpage, then on the wiki or in a TIP -- since script writers also need to know the recommended style for this occationally (e.g. when coding procs that do further syntax checks on an args argument and want to throw nice-looking error messages).
I disagree. We've never ever documented the format of syntax errors.
Here namespace, ensemble, and configure are actual arguments, whereas cmdname, opt, and value are formal arguments. This distinction could perhaps be shown somehow.
I disagree again. Mostly because it's awkward to render things in bold and italics without getting into other problems. "Check the manual page if you're confused, guys!" :-) I suppose we could do tricks like b^Hbo^Hol^Hld^HD or i^H_t^H_a^H_l^H_i^H_c^H_s^H_ but that's *really* ugly when it goes wrong or if you're trying to handle it with scripts.
Donal.
8 days ago, I started this thread and 3 people reacted. First of all,
a big thanks! It clearified a lot to me.
Then the result. Michael Kirkham came to the following conclusion:
> So, IMHO, this would be most correct and specific for procs:
>
> % proc foo {a b c args} something
> % foo x
> wrong # args: should be "foo a b c ?arg ...?"
and he gave a lot of pro's and contra's for each of the variations.
This variant was not in my list, but it actually is used in
a lot of places in Tcl, e.g.:
% encoding
wrong # args: should be "encoding option ?arg ...?"
% interp
wrong # args: should be "interp cmd ?arg ...?"
% namespace
wrong # args: should be "namespace subcommand ?arg ...?"
I have to agree with him, and with the other arguments given.
So, therefore I would like to declare this as the winner!!!!
2008/7/10 Donal K. Fellows <donal.k.fellows@manchester.ac.uk>:
> Lars Hellström wrote:
>> Whatever is chosen, the choice should be documented -- if not in a
> I disagree. We've never ever documented the format of syntax errors.
Documenting this has the disadvantage that we have to stick with
it and that we should take care that the Tcl core follows the
documentation.
2008/7/10 Donal K. Fellows <donal.k.fellows@manchester.ac.uk>:
> Lars Hellström wrote:
>> Here namespace, ensemble, and configure are actual arguments, whereas
>> cmdname, opt, and value are formal arguments. This distinction could perhaps
>> be shown somehow.
>
> I disagree again. Mostly because it's awkward to render things in bold and
> italics without getting into other problems. "Check the manual page if
> you're confused, guys!" :-) I suppose we could do tricks like
> b^Hbo^Hol^Hld^HD or i^H_t^H_a^H_l^H_i^H_c^H_s^H_ but that's *really* ugly
> when it goes wrong or if you're trying to handle it with scripts.
I don't want to add any more than consistancy, that's already work enough.
The reason I came up with this, is that I wrote a small proc in which the second
argument was a kind of subcommand, handled by a "switch". Later I rewrote
it using namespace ensemble, and noticed that the error-messages changed.
Regards,
Jan Nijtmans
Logged In: YES
user_id=61031
Originator: YES
fixed in Tcl 8.6a2