naviserver-devel

[naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Stephen,

Can you please give us some examples how to use the
ns_parseargs call? I would like to integrate this
in our code now and would need to instruct all my
collegues how to use it.

Just a couple of examples would be sufficient.

Thanks
Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/26/05, Zoran Vasiljevic <zv...@ar...> wrote:
> Stephen,
>=20
> Can you please give us some examples how to use the
> ns_parseargs call? I would like to integrate this
> in our code now and would need to instruct all my
> collegues how to use it.
>=20
> Just a couple of examples would be sufficient.
>=20
> Thanks
> Zoran


proc ex1 {args} {
    ns_parseargs {-a {-b ""} -- x {y Y} args} $args

    if {[info exists a]} {
        return [list $a $b $x $y $args]
    }
    return [list $b $x $y $args]
}


There's some use of ns_parseargs in the nstest_http proc of the test
harness, and of course in ns_parseargs.test.

We should probably define ns_proc to allow a more natural usage.  I
didn't do that at first as we were discussing extra features such as
type checking.  Do you think we can make that backwards compatible?

proc ns_proc {name spec body} {
    proc $name {args} "
        ns_parseargs $spec \$args
        $body
    "
}

ns_proc ex2 {-a {-b ""} -- x {y Y} args} {
    if {[info exists a]} {
        return [list $a $b $x $y $args]
    }
    return [list $b $x $y $args]
}

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 26.05.2005 um 17:41 schrieb Stephen Deasey:

>
> There's some use of ns_parseargs in the nstest_http proc of the test
> harness, and of course in ns_parseargs.test.
>

Another one:

How would I give a list of acceptable values to an option?
For example:

    -a (1|2|3)

so the value of "a", if given, can be one of 1, 2 or 3 but not 4?

(Qurious) Zoran

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 26.05.2005 um 17:41 schrieb Stephen Deasey:

> On 5/26/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
>> Stephen,
>>
>> Can you please give us some examples how to use the
>> ns_parseargs call? I would like to integrate this
>> in our code now and would need to instruct all my
>> collegues how to use it.
>>
>> Just a couple of examples would be sufficient.
>>
>> Thanks
>> Zoran
>>
>
>
> proc ex1 {args} {
>     ns_parseargs {-a {-b ""} -- x {y Y} args} $args
>
>     if {[info exists a]} {
>         return [list $a $b $x $y $args]
>     }
>     return [list $b $x $y $args]
> }
>
>
> There's some use of ns_parseargs in the nstest_http proc of the test
> harness, and of course in ns_parseargs.test.

Ah. Good tip. What I was also looking is the usage of "?" in the
specstring (never understood this one).

So, the "-a" will collect whatever comes after "-a" argument in
the arguments list and set the "a" variable to the value. Clear.
If I omit "-a" from the argument list, I can use specstring

   {-a a.default.value}

and this will set "a" variable with "a.default.value".

Now, where does the "?" come?
Also, how do I specify:

   myproc -booleanarg myarg
   myproc myarg

I'd want to have variable booleanarg set to 1 if i have "-booleanarg"
in argument list and set to 0 if I dont. How to specify this
(if possible at all; I recall there was an issue with that)?

Sorry for all this questions but this lies quite a few weeks
since we last talked about it...

>
> We should probably define ns_proc to allow a more natural usage.  I
> didn't do that at first as we were discussing extra features such as
> type checking.  Do you think we can make that backwards compatible?
>
> proc ns_proc {name spec body} {
>     proc $name {args} "
>         ns_parseargs $spec \$args
>         $body
>     "
> }
>
> ns_proc ex2 {-a {-b ""} -- x {y Y} args} {
>     if {[info exists a]} {
>         return [list $a $b $x $y $args]
>     }
>     return [list $b $x $y $args]
> }
>

Hmmm... what do you mean by "backwards compatible"?
The ns_proc does not exist, as I see, hence there
is no compatibility to look after. We can of course
define the ns_proc anytime and it can coexist with
the Tcl proc. Did I understand you correctly at all?

Apropos type-checking, I would not go to that extent.
The number, position and default values of arguments
seem pretty fine and sufficient. I would not like to
make it more complicated than absolutely necessary.

Cheer's
Zoran

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 26.05.2005 um 18:08 schrieb Zoran Vasiljevic:

>> proc ns_proc {name spec body} {
>>     proc $name {args} "
>>         ns_parseargs $spec \$args
>>         $body
>>     "
>> }
>>
>> ns_proc ex2 {-a {-b ""} -- x {y Y} args} {
>>     if {[info exists a]} {
>>         return [list $a $b $x $y $args]
>>     }
>>     return [list $b $x $y $args]
>> }
>

Ah.. you ment overriding "proc" itself?

So, instead of saying

   proc myproc {arg1 arg2 args} {
      ....
   }

one can also say:

   proc myproc {-a {-b ""} -- x {y Y} args} {
      ....
   }

So, in fact the "proc" becomes more clever?

Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/26/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Ah. Good tip. What I was also looking is the usage of "?" in the
> specstring (never understood this one).


The '?' signifies an optional argument, but it's used in the C API
only.  Tcl already has defaults, which is effectively an optional
argument.  Having the programmer explicitly handle optional args when
using the C API is faster and more natural, I think.

All that's surfaced in the Tcl API so far is options and the end of
options marker.  Args, defaults and the 'args' list is also
implemented, but of course that's standard Tcl behaviour.

Where we left the discussion last time is how to deal with type
checking.  Boolean switches and range values are basically just forms
of type checking.

Depending on how type checking is implemented, then the syntax of an
arg specification may change.  You may or may not end up pulling your
hair out later if you change all your code to use ns_proc now...  :-)

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 27.05.2005 um 11:34 schrieb Stephen Deasey:

> Where we left the discussion last time is how to deal with type
> checking.  Boolean switches and range values are basically just forms
> of type checking.

Hmm.... what I understood here was data-type checking as in
integer/string type of thing.

Under boolean support, I actually ment *absence* or *existence*
of the option. I do not know how I could achieve this now, unless
I say:

    ns_parseargs {{-boolean 0} args}

but this is also half-baked.

OK, lets think about type-checking. I would definitely say that
boolean type-checking (as described above) should be in.
The same for option-lists. Those two are most commonly found
and needed. Other type of checking would not be needed.
So, if I say:

     ns_parseargs {-a args}

then anything what is given to "-a" should be accepted as is.
Something like "string is ..." checking should be left to the
programmer.

I believe that underlying C-api already does the above, or?


>
> Depending on how type checking is implemented, then the syntax of an
> arg specification may change.  You may or may not end up pulling your
> hair out later if you change all your code to use ns_proc now...  :-)
>


Right. Lets fix this now. We can talk about the syntax when/if we
agree on the scope of the implemented type-checking (as above).
Deal?

Zoran 

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/27/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 27.05.2005 um 11:34 schrieb Stephen Deasey:
>=20
> > Where we left the discussion last time is how to deal with type
> > checking.  Boolean switches and range values are basically just forms
> > of type checking.
>=20
> Hmm.... what I understood here was data-type checking as in
> integer/string type of thing.
>=20
> Under boolean support, I actually ment *absence* or *existence*
> of the option. I do not know how I could achieve this now, unless
> I say:
>=20
>     ns_parseargs {{-boolean 0} args}
>=20
> but this is also half-baked.


Right, but the option list is type checking.  One of the syntaxes we
talked about was:

    ns_parseargs {-a:int -b:bool -s:switch} $args

So the boolean switch could use the type syntax.  I'm not desperate
for [string is ...] checks so leaving that out will certainly make
life easier, but we still have to think about the syntax for
specifying types as seems we need it anyway...


> OK, lets think about type-checking. I would definitely say that
> boolean type-checking (as described above) should be in.
> The same for option-lists. Those two are most commonly found
> and needed. Other type of checking would not be needed.
> So, if I say:
>=20
>      ns_parseargs {-a args}
>=20
> then anything what is given to "-a" should be accepted as is.
> Something like "string is ..." checking should be left to the
> programmer.
>=20
> I believe that underlying C-api already does the above, or?


You mean checking for integers etc.?  The C API does do this (has to,
it's C!), but the Tcl wrapper doesn't use it.  It was easier to define
a new Ns_ObjvSpec proc to handle all Tcl args than to massage the arg
spec into what the C API expects.  I don't know whether it makes sense
to try and use the underlying C stuff or not.

=20
> >
> > Depending on how type checking is implemented, then the syntax of an
> > arg specification may change.  You may or may not end up pulling your
> > hair out later if you change all your code to use ns_proc now...  :-)
> >
>=20
>=20
> Right. Lets fix this now. We can talk about the syntax when/if we
> agree on the scope of the implemented type-checking (as above).
> Deal?


Sure.  How would you specify an option list?  And would there be the
two types that the C API supports, the choose 1 and the choose 1 or
more?  For the choose 1 or more the result should probably be an array
(where the C implementation logically OR's bits).

So, with an option of -thingy where you can choose 1 or more of foo,
bar or baz, specifying -thingy {foo bar} would result in foo(bar) and
foo(baz) being set.


Maybe it would look something like this:

    ns_parseargs {{-thingy:either {foo bar baz}}} $args
    ns_parseargs {{-thingy:either {foo bar baz} foo} $args  ;# foo is defau=
lt

    ns_parseargs {{-thingy:any {foo bar baz}}} $args
    ns_parseargs {{-thingy:any {foo bar baz} {foo bar}} $args

i.e. either and any would have to be at least a two element list, the
optional third element being the default value.

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 27.05.2005 um 18:44 schrieb Stephen Deasey:

>     ns_parseargs {-a:int -b:bool -s:switch} $args
>
> So the boolean switch could use the type syntax.  I'm not desperate
> for [string is ...] checks so leaving that out will certainly make
> life easier, but we still have to think about the syntax for
> specifying types as seems we need it anyway...
>

Hmmm.... not very excited about the syntax, but have not any
other idea yet... will have to think about it.

>
>
> You mean checking for integers etc.?  The C API does do this (has to,
> it's C!), but the Tcl wrapper doesn't use it.  It was easier to define
> a new Ns_ObjvSpec proc to handle all Tcl args than to massage the arg
> spec into what the C API expects.  I don't know whether it makes sense
> to try and use the underlying C stuff or not.

Oh NO! Excatly that I did not wanted to do. I would not check argument
types on being integer or similar... This should really be left to the
programmer.

>
> Sure.  How would you specify an option list?  And would there be the
> two types that the C API supports, the choose 1 and the choose 1 or
> more?  For the choose 1 or more the result should probably be an array
> (where the C implementation logically OR's bits).

Do not know. I will invest some time in thinking about that tomorrow
morning...

Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/27/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Oh NO! Excatly that I did not wanted to do. I would not check argument
> types on being integer or similar... This should really be left to the
> programmer.


Well, OK.  I guess you can change your mind...  :-)

http://sourceforge.net/mailarchive/forum.php?thread_id=3D6839358&forum_id=
=3D43966

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 05:05 schrieb Stephen Deasey:

>
> Well, OK.  I guess you can change your mind...  :-)
>

Ehm... (blush) I frequently change my mind :-)
The thing is: I'd like to keep the spec as simple
as possible, otherwise you end up in tons of options
and very few people understand them and use them.

So, I'm back to work now and I have a whole day to
think about the options... Lets see what will pop
out of that ;-)

Zoran

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 27.05.2005 um 18:44 schrieb Stephen Deasey:

> Right, but the option list is type checking.  One of the syntaxes we
> talked about was:
>
>     ns_parseargs {-a:int -b:bool -s:switch} $args
>

Which seems really as the only meaningful, simple and easy
way to do this, I must admit, after thinking awhile.

So:

      ns_parseargs {{-varname?:type? ?default?} ...}

where -varname is going to set the variable "varname" and
it will first check, according to the ?:type? what it gets.
The best is to make some examples:

    -option

    would expect an argument and set "option" to argument value
    and if the -option is not given, will do nothing

    -option default

    if option is given, it will take it, otherwise will set the
    default value

    -option:flag

    if the option is given it will set it to the boolean true,
    otherwise to boolean false

    -option:oneof {a b c}

    if the option is given it will check the argument for being
    one of the a, b or c and set the variable accordingly.

Alternatively, one could use lists instead of ":" like this:

    {-option flag}
    {-option oneof {a b c}}

This is more Tcl-like and allows you freedom in the variable name.
Example:

   ns_proc connect {{-eightbit flag} {{-speed oneof {1200 2400 4800}}  
4800} {port /dev/ttya}} {
     # ...
   }

So I can say:

    connect
      and it will use 7bit comm, will take speed 4800 to connect to / 
dev/ttya

    connect /dev/ttyb
      as above but will connect to /dev/ttyb

    connect -speed 2400 /dev/ttyb
      as above but will use 2400bps instead of 4800bps

    connect -speed 9600 /dev/ttyc
      will throw error

    connect -eightbit /dev/ttyc
      will use 8bit comm to connect to /dev/ttyc

Apart from "flag" and "oneof" we can later introduce "int", "bool",  
"wide" etc
in order to additionaly check the given value:

     {{-number_of_retries int} 4}

Will expect number_of_retries to be an interger and if not given will  
set it to 4.

What do you think?
Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/28/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
> ...
>
> Alternatively, one could use lists instead of ":" like this:
>=20
>     {-option flag}
>     {-option oneof {a b c}}
>=20
> This is more Tcl-like and allows you freedom in the variable name.
> Example:
>=20
>    ns_proc connect {{-eightbit flag} {{-speed oneof {1200 2400 4800}}
> 4800} {port /dev/ttya}} {
>      # ...
>    }
>=20
> ...
>
> What do you think?


I think it looks like 'flag' is the literal default value for the
-eightbit option.  I do like the idea of lists, it is more Tcl-like.=20
But Tcl already has a syntax for procs, and this clashes with it.

To be compatible, the type specifier would have to be the third arg,
but then you couldn't specify the type without also specifying a
default.  I don't see a clean way to do it...

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 13:36 schrieb Stephen Deasey:

> To be compatible, the type specifier would have to be the third arg,
> but then you couldn't specify the type without also specifying a
> default.  I don't see a clean way to do it...


Hm.. so you are after

    arg {arg val} args

type of compatibility as in Tcl proc? I did not think about that
because we are using our own parser. What is the benefit/reason
to maintain this kind of compatibility when we already preprocess
args ourselves?

Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/28/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 28.05.2005 um 13:36 schrieb Stephen Deasey:
>=20
> > To be compatible, the type specifier would have to be the third arg,
> > but then you couldn't specify the type without also specifying a
> > default.  I don't see a clean way to do it...
>=20
>=20
> Hm.. so you are after
>=20
>     arg {arg val} args
>=20
> type of compatibility as in Tcl proc? I did not think about that
> because we are using our own parser. What is the benefit/reason
> to maintain this kind of compatibility when we already preprocess
> args ourselves?


It will confuse people who read the code, don't you think?

Some Unix utilities use + to signify flipping an option when ther are
many, so you could end up with something like this:

    ns_parseargs {+bool -opt {-opt def} arg {arg def} args}

This disadvantage of this is that you could not emulate some of the
standard Tcl commands...

I guess you could use all sorts of symbols:

    ns_parseargs {+bool -opt {=3Dchoice x {x y z}}}

Hmm, is it a problem that you have to supply a default if you want to
enforce choosing oneof many?  If the choices are contrained to x, y
and z but you also want to allow 'neither', couldn't you extend the
choices to 0, x, y, z, with 0 being the default?

Just throwing out ideas...

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 14:10 schrieb Stephen Deasey:

>> Hm.. so you are after
>>
>>     arg {arg val} args
>>
>> type of compatibility as in Tcl proc? I did not think about that
>> because we are using our own parser. What is the benefit/reason
>> to maintain this kind of compatibility when we already preprocess
>> args ourselves?
>>
>
>
> It will confuse people who read the code, don't you think?

I do but I do not care. It is the new functionality and
it has to be learned. Furthermore it is compatible to
usual Tcl syntax and is "natural" in the way it uses nested
lists. Admitently, it can grow complex, but the task ain't
simple anyway.


>
> Some Unix utilities use + to signify flipping an option when ther are
> many, so you could end up with something like this:
>
>     ns_parseargs {+bool -opt {-opt def} arg {arg def} args}
>
> This disadvantage of this is that you could not emulate some of the
> standard Tcl commands...
>
> I guess you could use all sorts of symbols:
>
>     ns_parseargs {+bool -opt {=choice x {x y z}}}
>
> Hmm, is it a problem that you have to supply a default if you want to
> enforce choosing oneof many?  If the choices are contrained to x, y
> and z but you also want to allow 'neither', couldn't you extend the
> choices to 0, x, y, z, with 0 being the default?

I also thought about using the first char as the type-selector
but it becomes weird if you are about to introduce other type-checking
like "int", "wide", "ascii", "print" (more generally, [string is...]
type of checks). Pretty soon you're out of signs and it is not very
illustrative/readable:

    +bool -opt =choice ?string &int

Hm... I do not think this will be very user-friendly...
Although the "user-friendliness" is not my first objective, it HAS
to be somehow "readable".

Zoran

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 13:36 schrieb Stephen Deasey:

>
> I think it looks like 'flag' is the literal default value for the
> -eightbit option.  I do like the idea of lists, it is more Tcl-like.
> But Tcl already has a syntax for procs, and this clashes with it.
>

Oh it does not!

    {{-eightbit flag}}

This is the correct syntax. If you wanted to have a default
it would be something like

    {{-eightbit flag} 1}

Generally, I do maintain the

    {option default}

form, just the "option" is now a list in itself, like:

    {{-flag oneof {a b c}} b}

The option is: {-flag oneof {a b c}}
Default value is: b

Clear?
Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/28/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 28.05.2005 um 13:36 schrieb Stephen Deasey:
>=20
> >
> > I think it looks like 'flag' is the literal default value for the
> > -eightbit option.  I do like the idea of lists, it is more Tcl-like.
> > But Tcl already has a syntax for procs, and this clashes with it.
> >
>=20
> Oh it does not!
>=20
>     {{-eightbit flag}}
>=20
> This is the correct syntax. If you wanted to have a default
> it would be something like
>=20
>     {{-eightbit flag} 1}


ns_parseargs {{-eightbit flag} {-foo flag} args}

How do you distinguish between -eightbit which is a boolean flag, and
-foo which is an option with a default string value of 'flag'?

I don't know that it makes much sense to supply a default for boolean
flags.  In that case you probably want to invert the sense of the flag
name: -nofoo.

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 14:19 schrieb Stephen Deasey:

>
>
> ns_parseargs {{-eightbit flag} {-foo flag} args}
>
> How do you distinguish between -eightbit which is a boolean flag, and
> -foo which is an option with a default string value of 'flag'?

Here is how:

     ns_parseargs {=10=10{{-eightbit flag}} {-foo flag} args}

The first argument of the above spec is:

      {{-eightbit flag}}

which is a one-element list.

Generally you'd have:

     {{spec} {spec} {spec} args}

where "spec" is:

     {option value}

where option is:

     {-variable type ?type_specific_part?}

The "type_specific_part" whould be a choice-list for "oneof" type, =20
for example.
This is just a nested-list exercise. It is Tcl-natural and can become
difficult to write with all those curly braces, but that's the price
of the flexibility.

>
> I don't know that it makes much sense to supply a default for boolean
> flags.  In that case you probably want to invert the sense of the flag
> name: -nofoo.

There is no sense in supplying defaults for boolean flags, but the
syntax would/must allow it (i.e. special case).

Zoran

Re: [naviserver-devel] ns_parseargs example

[Stephen D. <sd...@gm...>]

On 5/28/05, Zoran Vasiljevic <zv...@ar...> wrote:
> Am 28.05.2005 um 14:19 schrieb Stephen Deasey:
> >
> > ns_parseargs {{-eightbit flag} {-foo flag} args}
> >
> > How do you distinguish between -eightbit which is a boolean flag, and
> > -foo which is an option with a default string value of 'flag'?
>=20
> Here is how:
>=20
>      ns_parseargs {=10=10{{-eightbit flag}} {-foo flag} args}


Ouch!


> This is just a nested-list exercise. It is Tcl-natural and can become
> difficult to write with all those curly braces, but that's the price
> of the flexibility.

...

> > It will confuse people who read the code, don't you think?
>
> I do but I do not care.


I think you're optimising for the wrong thing... :-(

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 15:50 schrieb Stephen Deasey:

>>
>> Here is how:
>>
>>      ns_parseargs {=10=10{{-eightbit flag}} {-foo flag} args}
>>
>
>
> Ouch!

:-)

>>> It will confuse people who read the code, don't you think?
>>>
>>
>> I do but I do not care.
>>
>
>
> I think you're optimising for the wrong thing... :-(

Well... trying to keep the {option value} format
and introducing more options...

One can also use the

    -option:type

but this will save you just one list level if you want
to be Tcl-proc compatible.

OTOH, if you *do not* expect the 100% compatilibity with
the Tcl proc, then other possiblities open, of course.
So:
     ns_proc {
              -retries  {default 4 type int}
              -eightbit {type flag}
              -speed    {default 2400 type {oneof {1200 2400 4800}}}
              devpath   {default /dev/ttya}
             } {
        #....
    }

Ouch?

The thing is: we'd like to force a large foot into a small shoe!
This will not go without cutting the toes or drilling the hole
in the shoe :-)
When I look this from another perspective: the best way would
be to go and buy larger shoes!
Or, to quote some american indian: when you discover you're
riding a dead horse the best strategy is to dismount.

So what's from above: cut toes, drill holes, buy shoes or dismount ??

Zoran

>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-=20=

> q22005
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] ns_parseargs example

[Zoran V. <zv...@ar...>]

Am 28.05.2005 um 16:26 schrieb Zoran Vasiljevic:

>
> So what's from above: cut toes, drill holes, buy shoes or dismount ??
>

I will answer this myself: cut toes!

Lets KISS (Keep It Simple and Stupid).

There are no boolean flags.
There are no choice lists.
There is no other type of checking.
We only check "-" prefixed arguments to be optionally set (or not)
We allow defaults for opional args.

Pros:

o. all is already in place (we do not need to write anything more)
o. we are keeping Tcl philosophy of typeless arguments
o. it is easy to write/code

Cons:
o. all checking (except for parsing-out optional args)
    must be done by the programmer him/herself

I knew that this damn checking will lead us to complications.
Therefore: forget it.
What do you think? Ouch again?

Zoran