There are several pages on the wiki regarding different methods for argument parsing and its cousin, named arguments.
This page is for general discussions regarding a potential system that might satisfy both of those.
Here we can toss back and forth general design questions, key concerns being:
- Which feels the most TCL-like
- Which might sacrifice some freedom for power

One that I've been working on here and there uses a prefix notation in the proc definition for the named argument system
to know what to do with.  For instance:

 proc foo { fname o_lname } {
      puts "$fname"
 }

 foo "Richard" -lname "Pryor"
 
Here, the lname is understood by a wrapping proc to be "switchable", and the proc also understands that fname is a required
argument, and should not be "named".  What do people feel about similar ideas to expand the proc definitions?  Another idea is to implement some sort of enumerated definition in the proc "e_actiontype", where actiontype might be defined, maybe within the proc body, or a central location.
----
''[escargo] 19 Sep 2005'' - I think it might be fruitful to consider why there are so many
implementations of argument processing.

   * What are the underlying problems to be solved by centralizing argument processing?
   * What are advantages and disadvantages of the different implementations?

Using one body of code to process arguments levies certain requirements.

   1. There must be a way of specifying the arguments and how they are processed.
   1. There must be a way of specifying what to do with arguments that are not recognized.
   1. There must be a way of returning the results of processing arguments.
   1. There might be a way of returning arguments that are not processed.

I have seen some systems where there is an explicit grammar that specifies command arguments;
each command can hand off a string containing its argument description in that grammar to an
argument parsing service.
----

''[IL] 19 Sep 2005'' - I think you've summarized the goals well.  I'd note with all of tcl's nice introspection capabilities, one 
could probably fashion a general handler, instead of hardcoding the relationship to the underlying proc.  For myself, I'd love a system that can enables a user to have a light encapsulation around user defined procs that emulates the tcl commands.  For instance:

 proc parse args {} {
 }
 proc parse_html_links { o_all o_img o_href html } {
 }

could be invoked in the tcl command way, and be understand as being part of a "parse" command set.
The first definition could be the router/service.

 set links [parse html links -all -href $html]
 set link [parse html links -img $html]

This has several advantages over using the default tcl proc system:
   * It allows for a readable, definable packaging system but with a generalized implementation
   * The syntax allows for easy modification of the internals by decoupling argument order and required parameters

''[NEM] 19 Sep 2005'': I'm not a big fan of the o_ prefix, or the _ convention. The first looks a bit like Hungarian notation,
and the latter is already served by :: and the new ''[namespace ensemble]'' in 8.5. Regarding argument parsing and
named arguments, I'd prefer a simple option-parsing command that takes a list of parameters in the same form that proc does,
along with a list of arguments and returns a dictionary of the values, or an error if some parameter has not been specified.
e.g.:
 proc person args {
     set details [option parse {name age {weight 100} {shoesize 10}} $args]
     dict with details { .... }
 }
 person -name "Neil" -age 24

("option" is unfortunately a Tk command, though). That seems like the best separation of concerns: doesn't force anybody to use
it; can be selectively applied to groups of arguments; and can be wrapped into a higher-level construct easily enough. I would 
prefer it if the command parsed arguments such that any parameter could be specified either positionally or using -name value
syntax (although the first positional argument turns off the -name value parsing). The behaviour could then mimick current
proc-style parsing by default (something I've needed on occassion), but also then handle named arguments. e.g.:

 proc apply {lambda args} {
    lassign $lambda params body
    set d [option parse $params $args]
    dict with d $body
 }
 set cmd [list {a b {c 12}} { expr ($a*$b)/$c }]
 apply $cmd 1 2
 apply $cmd 2 4 10.0
 apply $cmd -a 12 15 24 ;# a=12, b=15, c=24

The ability to specify any parameter using the named form is useful for currying when arguments may be accepted in the wrong order.

[escargo] - Maybe there are '''three''' different contexts in which argument parsing occurs:

   1. Shell-level (command prompt) commands that communicate with [Tcl] scripts as system executables.
   1. Script-level commands that try to look like shell-level commands.
   1. Script-level commands that try to look like [Tcl] proc invocations.

I have implemented command parsing (shell-level) that tried to allow for either command line or graphical
control.  There was metadata associated with each command parameter so that the command parser could generate
either a text-based or graphical interface to get operator inputs.

   Flag parameters:   Flag name, description.  On a command line expected something like -D or nothing; for a GUI generated a checkbox.
   Enumerated parameters:   Parameter name, description, list of legal values.  On a command line expected something like -param ''value'' where ''value'' had to be one of the list of legal values; for a GUI generated a radio button group.
   Value parameters:   Parmeter name, description, type information.  On a command line expected something like -param ''value'' where ''value'' had to conform to the type information; for a GUI generated a entry widget that called a validator using the type information.

Part of the metadata is whether the argument is optional or not; for file names, metadata including information
about whether the file had to already exist or not (or didn't matter).  Parameters could also be considered to
be required.  There could also be specification of default values.  (Usually I have seen parameters with default
values to be optional.  Required parameters are of course not optional.)

Some parameters were ''list'' parameters, where there was no preceding parameter name.  Typically these were
lists of file names (usually one or more).

I see help in argument parsing to be of most use for 1 and 2. I'm not quite sure why one would want to
use it for the 3rd case.

----
[Category Argument Processing] | [Category Discussion]