Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Neil M. <ne...@Cs...>]

Andreas Leitgeb wrote:
> On Sun, Nov 23, 2008 at 01:16:15AM +0000, Neil Madden wrote:
>> I believe I proposed a "--" didn't I?
> I just meant that the "--" should even then be kept, if all other
> options were deferred for later (if at all)
> 
>>> [ {POSIX *} ] somehow does strike me as odd, [...as...], we
>>> are *supposed* to use a string operation (pattern-matching)
>>> on a list ($errorCode).
>>> Perhaps this pattern should be itself taken as a list, and then
>>> glob-matched element-wise (to the length of the pattern).
>> This is exactly the purpose of -matchcommand.
> 
> But my point was, that a list-aware matching should happen by 
> default, such that most of the cases it works correctly, even 
> without implementing and installing a custom matcher.
> 
> If usage of errorCode catches on (as a hoped-for result of the
> new try-command), then sooner or later someone will define
> sub-types like "ARITH MATRIX" and wonder, why ARITH* doesn't
> match both ARITH and "ARITH MATRIX".
> It of course doesn't match the latter, because that actually
> looks like "{ARITH MATRIX} ..." thus would need an optional
> open brace be matched as well (How to do that with globs?)
> And then it may even look like "ARITH\ MATRIX ..." sometimes,
> namely if some later element of the errorCode happens to 
> contain an unpaired brace. 

% string match ARITH* [list ARITH MATRIX]
1
% string match ARITH* [list ARITH MATRIX \{]
1
% string match ARITH* [list ARITH MATRIX \}]
1
% string match ARITH* {ARITH MATRIX \}}
1

It works fine. It would fail on [list [list ARITH MATRIX]]. The only 
problem is that it is only capable of recognising very simple regular 
languages, whereas list syntax is context-free so you can't match parts 
of nested sublists very easily (or at all). Twylite has convinced me 
that glob matching is sufficient for 80+% of basic cases for [try]. 
There is no general list-pattern syntax in Tcl at the moment, so doing 
something more would require a much expanded scope for the TIP. List 
pattern matching is much more tricky due to the requirement to know what 
the expected types of elements are (so you can reliably distinguish 
sub-lists from strings and so on).

[...]
> Introducing a list-string mixup directly in the core 
> is a very bad move, imho.

I think it's fine in this case. No errors can arise because of it. We 
are not constructing or extracting lists here, just a simple match. We 
don't have to worry about balanced braces or quoting issues.

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.