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.
Using one body of code to process arguments levies certain requirements.
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.