Richard Suchenwirth 2004-01-25 - Languages like Lisp and Python have the docstring feature, where a string in the beginning of a function can be retrieved for on-line (or printed) documentation. Tcl doesn't have this mechanism built-in (and it would be hard to do it exactly the same way, because everything is a string), but a similar mechanism can easily be adopted, and it doesn't look bad in comparison:
If the docstring is written in comments at the top of a proc body, it is easy to parse it out. In addition, for all procs, even without docstring, you get the "signature" (proc name and arguments with defaults). The code below also serves as usage example:
proc docstring procname {
# reports a proc's args and leading comments.
# Multiple documentation lines are allowed.
set res "{usage: $procname [uplevel 1 [list args $procname]]}"
# This comment should not appear in the docstring
foreach line [split [uplevel 1 [list info body $procname]]] {
if {[string trim $line] eq ""} continue
if ![regexp {\s*#(.+)} $line -> line] break
lappend res [string trim $line]
}
join $res
}
proc args procname {
# Signature of a proc: arguments with defaults
set res ""
foreach a [info args $procname] {
if [info default $procname $a default] {
lappend a $default
}
lappend res $a
}
set res
}Testing:
% docstring docstring usage: docstring procname reports a proc's args and leading comments. Multiple documentation lines are allowed. % docstring args usage: args procname Signature of a proc: arguments with defaults
2014-01-12: I think maybe there is a mistake here? For me, the docstring command doesn't work unless I specify splitting at newlines (and then joining with newlines on return):
proc docstring procname {
# reports a proc's args and leading comments.
# Multiple documentation lines are allowed.
set res "{usage: $procname [uplevel 1 [list args $procname]]}"
# This comment should not appear in the docstring
foreach line [split [uplevel 1 [list info body $procname]] \n] {
if {[string trim $line] eq ""} continue
if {![regexp {\s*#(.+)} $line -> line]} break
lappend res [string trim $line]
}
join $res \n
}I also took the liberty of bracing the second if's condition.
For my own use, I've added separation of namespace qualifiers from base proc name (the namespace string is blank for the global namespace):
proc docstring procname {
# reports a proc's args and leading comments,
# separating namespace qualifiers from base proc name.
# Multiple documentation lines are allowed.
set res "{usage: [namespace tail $procname] [uplevel 1 [list args $procname]]}"
lappend res "namespace: [namespace qualifiers $procname]"
# This comment should not appear in the docstring
foreach line [split [uplevel 1 [list info body $procname]] \n] {
if {[string trim $line] eq ""} continue
if {![regexp {\s*#(.+)} $line -> line]} break
lappend res [string trim $line]
}
join $res \n
}
namespace eval ::Foobar {
proc foo {bar {baz qux}} {
# This command foo:s all bar:s in the baz range
# (by default qux).
return {the end}
}
}
% docstring ::Foobar::foo
usage: foo bar {baz qux}
namespace: ::Foobar
This command foo:s all bar:s in the baz range
(by default qux).NEM (23Feb2005) offers the following simple proc:
# describe.tcl --
#
# Simple documentation comments.
#
# Copyright (c) 2005 Neil Madden.
# License: Tcl/BSD-style
package provide describe 1.0
namespace eval describe {
variable desc
array set desc {}
}
proc describe {cmd args} {
if {[llength $args] > 1} {
return -code error "wrong # args: should be \"describe cmd ?description?\""
}
set name [uplevel 1 [list namespace which -command $cmd]]
if {[llength $args] == 1} {
set ::describe::desc($name) [lindex $args 0]
} else {
if {[info exists ::describe::desc($name)]} {
return $::describe::desc($name)
} else {
return "no description available"
}
}
}describe describe "usage: describe cmd ?description? Gets or sets a textual description associated with a command."
It works like so:
% describe describe usage: describe cmd ?description? Gets or sets a textual description associated with a command. % describe set no description available % describe set "usage: set var ?value? Gets or sets the current value of a variable" usage: set var ?value? Gets or sets the current value of a variable % describe set usage: set var ?value? Gets or sets the current value of a variable
Advantages are that it separates the documentation from the implementation of a command, so you can add descriptions for C-coded commands (including built-ins), and you could localise the descriptions by having separate description files loaded for different languages (useful if you were using the descriptions for tooltips in a GUI, say). It also works for objects, widgets, etc - anything which has a command interface. Disadvantages are that it separates the documentation from the implementation of a command ;) i.e. the descriptions may not be next to the implementations, so people may forget to keep them up-to-date.
LES on 20070528: I use a slightly different approach. I have a big mama file with lots of procs that I reuse all the time and sometimes I forget how to use one of them. Since I am on Tkcon most of the time, I implemented it like this:
proc procdoc {args} {
# proc 2 of 86
# prints the name, arguments and documentation of current parent proc
# it accepts "args", but only ? is recognized to trigger this help text
if {[lindex $args 1] eq "?"} {procdoc}
set _wholeProc [info level -1]
set _procName [@ $_wholeProc 0]
set _procArgs [info args $_procName]
set _procBody [info body $_procName]
# set initial ProcDoc content:
set _procDoc "$_procName $_procArgs \n\n"
# turn proc's body into a list
set _procBody [split $_procBody "\n"]
# remove first element because it is always empty
set _procBody [lrange $_procBody 1 end]
# iterate on _procBody
# keep getting lines that start with #; stop when we run out of them
for {set i 0} {$i < [llength $_procBody]} {incr i} {
set _line [lindex $_procBody $i]
if {[regexp {^\s*#.*} $_line] == 0} {break}
append _procDoc "$_line\n"
}
# remove trailing line break
regsub (.*)\n $_procDoc \\1 _procDoc
return "usage: $_procDoc"
}Which captures the initial comments in all other procs that contain the magic line (if {[lindex [info level 0] 1] eq "?"} {procdoc; return}) and displays them whenever "?" is the first argument (the proc may require several arguments):
proc demonstration {thisArg thatArg} {
# proc 19 of 86
# Two arguments required: thisArg does this, thatArg does that.
# This proc is a quick and dirty demonstration
# to those nice folks at wiki.tcl.tk
# Every proc has to contain this next line:
if {[lindex [info level 0] 1] eq "?"} {procdoc; return}
catch {{do some stuff} dothis dothat} Data
return $Data
}Test:
% demonstration ? wrong # args: should be "demonstration thisArg thatArg ..." % demonstration ? ? usage: demonstration thisArg thatArg # proc 19 of 86 # Two arguments required: thisArg does this, thatArg does that. # This proc is a quick and dirty demonstration # to those nice folks at wiki.tcl.tk # Every proc has to contain this next line:
But the error itself (introspection) is enough to provide the required arguments, you'd think. Yes, but it does not provide the detailed explanation. Most of my procs take just one or no argument, so I usually get my little canned help right away instead of the error message.
My variant [L1 ] supports Itcl classes, usual procs, also generates documentation file (in .rst format). Example of usage:
proc f {args} {
# help on command:
# opt1 - ...
# opt2 - ...
# ... code ...
}
# or
itcl::class C {
method m {args} {
# Syntax:
# -opt1 - ...
# -opt2 - ...
# ... code ...
}
}
# usage
doc f
doc C m
C theC
doc theC m
_gendoc help.rst; # saving help file as ReSTructuredTextSEH 20120312 -- The OpenACS project makes heavy use of an expanded-features proc called ad_proc [L2 ], which provides enhanced options for specifying arguments and includes a docstring field. It's free of OpenACS dependencies and thus can be used on its own. The ad_proc code has also been incorporated into the nstcl-core package.
See also: Ruff!