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.  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_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.

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

This has several advantages over using the defaulttcl 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

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