TIP #65: Enhanced [info args]
Glenn Jackman
TIP #65: ENHANCED [INFO ARGS]
===============================
Version: $Revision: 1.1 $
Author: Glenn Jackman <gle...@nortelnetworks.com>
State: Draft
Type: Project
Tcl-Version: 8.4
Vote: Pending
Created: Tuesday, 18 September 2001
URL: http://purl.org/tcl/tip/65.html
WebEdit: http://purl.org/tcl/tip/edit/65
Post-History:
-------------------------------------------------------------------------
ABSTRACT
==========
This TIP proposes a new subcommand to the [info] command be added that
would return the list of arguments, together with any default values in
the same format as the _args_ parameter to the [proc] command.
INTRODUCTION
==============
The [proc] man page defines _args_ as:
... the formal arguments to the procedure. It consists of a list,
possibly empty, each of whose elements specifies one argument.
Each argument specifier is also a list with either one or two
fields. If there is only a single field in the specifier then it
is the name of the argument; if there are two fields, then the
first is the argument name and the second is its default value.
Suppose we define a procedure like this:
proc test {one {two 2} {three {3 4 5}} args} {return}
We want to determine the formal arguments for this procedure. We want
some method to return the list:
one {two 2} {three {3 4 5}} args
[info args] fails us because it does not return default values, only
the list of argument names {one two three args}.
The [info default] command exists, and does partially what we want.
However [info default] only operates on a single argument. To determine
the complete list of arguments with default values, we must iterate
over the arguments returned by [info args]. We would define a procedure
like:
proc info_args_with_defaults {procname} {
set argspec [list]
# [info args] throws an error if $procname is not a procedure.
foreach arg [info args $procname] {
if {[info default $procname $arg value]} {
lappend argspec [list $arg $value]
} else {
lappend argspec $arg
}
}
return $argspec
}
info_args_with_defaults test ;# ==> returns {one {two 2} {three {3 4 5}} args}
A more sophisticated scripted solution is to overload the [info]
command itself, as described in the Wiki at
<URL:http://purl.org/thecliff/tcl/wiki/WrappingCommands>
It would be much more convenient to be able to rely on the [info]
command itself to return the desired information, particularly since it
_almost_ does what we want already.
_This topic was originally raised in the <URL:news:comp.lang.tcl>
newsgroup in the thread
<URL:http://groups.google.com/groups?th=4b0d5dba85d2c160>_
SPECIFICATION
===============
With the goal of maintaining backwards compatibility in mind, two
possibilities arise: adding a new switch to the existing [info args]
command, and adding a completely new subcommand to [info].
Adding a switch to [info args] may break backwards compatibility. If we
use the syntax [info args _?-withdefaults? procname_], there may be
trouble with existing scripts containing a procedure named
"-withdefaults". The syntax [info args _procname ?-withdefaults?_] is
completely backwards compatible. However, among Tcl commands that take
subcommands, there is currently some inconsistency as to where switches
should appear. [clock] subcommands place these options after required
parameters. [namespace] and [package] subcommands place these options
before required parameters. Some [file] subcommands put them before,
some after. Currently, no [info] subcommands take switches.
Rather than compound to this inconsistency, creating a new [info]
subcommand feels cleaner. Possible names include:
argspec, arglist, args_with_defaults:
These all collide with the "arg", "ar", "a" shorthands for [info
args _procname_]. And _args_with_defaults_ is just *way* too
ugly.
formalargs, fullargs:
Either of these could be used. There are no [info] subcommands
beginning with "f".
parameters: This collides with the "pa" shorthand for [info patchlevel]
prototype: This collides with the "pro" and "pr" shorthands for [info
procs _?pattern?_]
signature: This could be used, as it does not collide with any
shorthand for either [info script] or [info sharedlibextension].
The term "signature" has meaning in the Java and C++ worlds: the
function name and its arguments together comprise the signature. The
purpose of this TIP is to return only the arguments with any defaults,
so to avoid any potential confusion I will rule out "signature".
Of the remaining possibilities, my choice would be "formalargs". The
term "formal arguments" is used in the [proc] man page. "formalargs"
also incorporates the word "args", indicating a relationship to [info
args].
REFERENCE IMPLEMENTATION
==========================
Refer to the submitted patch, which implements an subcommand named
[info fullargs], at:
<URL:http://sourceforge.net/tracker/index.php?func=detail&aid=461635&group_id=10894&atid=310894>
COPYRIGHT
===========
This document has been placed in the public domain.
-------------------------------------------------------------------------
TIP AutoGenerator - written by Donal K. Fellows
[[Send Tcl/Tk announcements to tcl-an...@mitchell.org
Send administrivia to tcl-announ...@mitchell.org
Announcements archived at http://groups.yahoo.com/group/tcl_announce/
The primary Tcl/Tk archive is ftp://ftp.neosoft.com/pub/tcl/ ]]
Chris Nelson
> ...
> This TIP proposes a new subcommand to the [info] command be added that
> would return the list of arguments, together with any default values in
> the same format as the _args_ parameter to the [proc] command.
I think this is a good enhancement.
> ... creating a new [info]
> subcommand feels cleaner. Possible names include:
>
> argspec, arglist, args_with_defaults:
> These all collide with the "arg", "ar", "a" shorthands for [info
> args _procname_]. And _args_with_defaults_ is just *way* too
> ugly.
>
> formalargs, fullargs:
> Either of these could be used. There are no [info] subcommands
> beginning with "f".
>
> parameters: This collides with the "pa" shorthand for [info patchlevel]
>
> prototype: This collides with the "pro" and "pr" shorthands for [info
> procs _?pattern?_]
>
> signature: This could be used, as it does not collide with any
> shorthand for either [info script] or [info sharedlibextension].
>
> The term "signature" has meaning in the Java and C++ worlds: the
> function name and its arguments together comprise the signature. The
> purpose of this TIP is to return only the arguments with any defaults,
> so to avoid any potential confusion I will rule out "signature".
>
> Of the remaining possibilities, my choice would be "formalargs". The
> term "formal arguments" is used in the [proc] man page. "formalargs"
> also incorporates the word "args", indicating a relationship to [info
> args].
I kind of like argsspec or arglist but I can live with formalargs.
FWIW, I'd comment that not colliding with an abbreviation for an
existing command is a very weak argument; I _never_ use abbreviations,
even interactively and believe that using them in scripts is risky and
you get what you deserve if a new command creates a conflict.
Chris
--
Given infinite time, everything will happen.
Glenn Jackman
>FWIW, I'd comment that not colliding with an abbreviation for an
>existing command is a very weak argument; I _never_ use abbreviations,
>even interactively and believe that using them in scripts is risky and
>you get what you deserve if a new command creates a conflict.
Do any Tcl core maintainers have opinions on this question: How
important is maintaining backwards compatibility for abbreviations
between minor releases?
--
Glenn Jackman
Don Porter
>>FWIW, I'd comment that not colliding with an abbreviation for an
>>existing command is a very weak argument; I _never_ use abbreviations,
>>even interactively and believe that using them in scripts is risky and
>>you get what you deserve if a new command creates a conflict.
Glenn Jackman <gle...@nortelnetworks.com> wrote:
>Do any Tcl core maintainers have opinions on this question: How
>important is maintaining backwards compatibility for abbreviations
>between minor releases?
My opinion: it has no importance whatsoever. Real programs should
spell out all subcommands and switches. Abbreviations are only
for interactive convenience.
Nevertheless, I still think "formalargs" was the best choice. :)
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Jeff Hobbs
The Tcl style guide states that abbreviations shouldn't be used,
but we all know that people do use them. There are common ones,
like 'info shared' instead of 'info sharedlibextension', and
'file isdir' instead of 'file isdirectory'. It depends on what
sort of abbreviation we are looking at. Something like 'info s'
is not sacred, but 'info shared' is, even between minor versions.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions