Re: [TCLCORE] Data-dependent bugs in TIP #457

[Mathieu L. <ml...@gm...>]

Thanks Christian for this very detailed and interessant write-up.

> but fails when a dash is present [1]:
>
>    (test) 119 % set list {-value some other thing}
>    -value some other thing
>    (test) 120 % mylsort -dictionary $list
>    wrong # args: should be "mylsort
> ?|-ascii|-dictionary|-integer|-real|? list"
>
> whereas the original lsort has no problem:
>
>    (test) 121 % lsort -dictionary $list
>    -value other some thing
>
> It even breaks EIAS [1]:
>
>    (test) 122 % lindex $list 0
>    -value
>    (test) 123 % mylsort -dictionary $list
>    Sort mode dictionary
>    -value other some thing

Well spotted! It's because the internal type can change during time:
what is initially a string become a list after the [lindex] call, and
trigger the multi-elements test which end the named-group handling.
Testing if the string can be an array would be possible, but would
forbid the use of spaces in names.

I understand there is a coherency problem here that must be addressed.

> This always works, but it puts the burden on the programmer to add -- at
> all invocations.

Unix has several decades of history using an end-of-option marker to
end a named group to use an argument with a leading dash or to use an
external/unverified argument which may start with a dash. We are all
used to it, I don't think it is a burden.

> A possible solution would be first to detect, if the argument list can
> be parsed unambiguously. In that case, create an interface like lsort.

You have nearly convice me on that case (especially if we want to
replace similar functions without modifying the usage), although the
user's documentation will probably be a little more complicated. I
will think about it.

> Second, if it is determined, that there is ambiguity, this could raise
> an error. Either the new proc-457 *disallows* mixing variable number of
> arguments with named arguments, [...]

I don't think we should disallow that.

> [...] or it throws a runtime error *upon
> invocation*, if "--" was not seen in the argument list.

That would be the safer thing to do. *But* searching for "--" would
still require to stringify the argument list (although most non-string
objects can probably be easily skipped in that case).

> It might also be possible to come up with a set of rules, how to assign
> the arguments in a way that the common cases do not bear a surprise.
> While it might be tricky to derive these rules or prove that they work
> as intended, it could be a way to formalise the sensible expectation. I
> am still hoping that Kevin Kenny can find the rules he formulated some
> time back.

If your talking about rules which can prevent users to explicitely use
"--" for common cases, I'm interested to hear about them.

> [...] all in al this TIP is not bad and there hase
> been a lot of work going into the amalgamation of a syntax which seems
> very Tclish and a good overall compromise.

Thank you for your support.

-- Mathieu