[TCLCORE] TIP #329 [try] updated

[Andreas L. <av...@lo...>]

Twylite <tw...@cr...> wrote:
> Case in point: we have an API for accessing a hardware coprocessor 
> (let's call the API "ABC").  The coprocessor returns numeric error 
> results in the range 1 to 99.  So we defined the -errorcode to be [list 
> ABC $errnum], e.g. "ABC 4".
> A little while later we realised that error 4 is quite special -- it is 
> allowed to return an extended error information field (the coprocessor 
> had to maintain the use of error 4 for backwards compatibility, but 
> there were times when knowing the exact cause was important).  So we 
> extended the -errorcode in this case to [list ABC $errnum $extra], e.g. 
> "ABC 4 F".

Using list-patterns of course adresses this usecase just perfectly.
{ABC 4} would match "ABC 4 F" as well as "ABC 4 whatever" and also
just "ABC 4",  but still would not match "ABC 42".
{ABC 4 [A-C]} could furthermore be used to match "ABC 4 B" but not
"ABC 4 F.

I guess it will take a few years from now till Donal runs into such
a practical usecase himself, and at that point we will perhaps add
a new ltrap clause with just that type of matching.  Adding it now
would unfortunately put the TIP at risk.

Joe English <jen...@fl...> wrote:
> Just about every other language with a try/catch/finally
> statement binds variables as part of the handler clause;

tcl is different :-)   In this particular case, I even think
it's good so. The resultvar's typical name may be confusing
for the "on ok" block, but one can easily assign it to
a better variable inside the block, if the information is
later needed with an apt name. The "on ok" block is likely
to be rather a rare case.
Other languages have only one exception-variable, and that's
length is generally much smaller than the length of the 
exception name, so two more chars don't hurt. Also in the
other languags the names of the variables aren't visible
anymore after the block.  In tcl's try, having to specify
a variable for each handler would make it much more bulky:
  try {...} trap {{MYERR FOO} vMsg vDict} {...}
And since each variable would outlive the handler, we'd have
a bulk of possibly but not always defined variables afterwards.

In a nutshell:  just because in tcl the error-variables are broader
scoped, it makes sense to define them globally to the try-command.

Twylite <tw...@cr...> wrote:
> So far the opinion seems to be that a list prefix is too limited,
> and a list pattern match (per element glob) is too difficult
That's relative to its perceived usefulness.
> and has no existing reference.
Many things in tcl haven't.

> The intended manner for extending [try] is by adding new handler 
> keywords (if the existing ones are not handling the required use cases).
... ltrap {ABC 4} ...