Re: [TCLCORE] TIP #329 [try] updated

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

On 2 Dec 2008, at 09:21, Twylite wrote:
> Further feedback on error matching:
>
> It looks like glob matching is not going to cut it.  List prefix
> matching will be a similarly-powerful and generally safer approach.
>
> Looking at the functionality of other exception matching systems,  
> we can
> see that Java (with single inheritance) is the equivalent of matching
> against a tree, and C++ (with multiple inheritance) is the  
> equivalent of
> matching against a Directed Acyclic Graph.
>
> Neither string matching nor list prefix matching nor element-wise list
> matching give the functionality of a tree match.
>
> Example:
>
> In Java you may define a MyIOException extends IOException (extends
> Exception extends Throwable).  Code using your API will
>    catch (MyIOException e) { // handle it }
>
> You can safely subclass MyIOException and throw these subclasses  
> without
> breaking code that catches MyIOException (as in the example above).
>
> You can also safely introduce a new superclass between IOException and
> MyIOException (MyCompanysGenericIOException) without breaking code  
> that
> catches MyIOException.

This is because inheritance matching is encapsulated, whereas as  
pattern matching on a concrete data structure isn't. If you really  
want to support these use-cases then they way to go is to use TclOO.

> In C++ you could introduce a completely new base class to  
> MyIOException
> via multiple inheritance, without breaking existing code.

Likewise in Java you can happily add new interfaces (implements  
Blah...).

> With glob/list/prefix matching you can support either subclassing or
> superclassing the error, not both, and not MI.  You cannot use glob/ 
> list
> matching safely to allow for superclassing (don't got there --  
> think of
> the pattern "Throwable * FormatException *" and how many third party
> APIs are going to have something called "FormatException" and you'll
> understand the folly of this approach).
>
> So while element-wise list matching may SEEM really powerful, its  
> just a
> knapsack with a big gun and rope.  Similarly a glob match may seem
> flexible, but in most cases its going to be used a prefix match, and
> often used incorrectly such that it prevents subclassing of errors in
> future.
>
> So, in the absence of an approach to tree/DAG matching, a list prefix
> seems like the most sensible option.

Well, the most flexible form of (concrete) pattern matching is the  
algebraic sort found in functional programming languages: that can  
match anything expressible as a sum-of-products, which includes  
lists, trees, and so on. It still matches against a concrete data- 
type, however, so the use-cases you imagine would still break. The  
only real way to get around that is encapsulation of the matching,  
which can be achieved either by making the new data structure look  
like the old ("views"), or by defining something like an abstract "is- 
a" relation. If you want full flexibility and the ability to match  
arbitrary DAGs then there's always Prolog.

Most of those suggestions aren't practical, at least not with current  
Tcl. Inheritance based matching using TclOO is practical, but would  
represent a radical departure from the way -errorcode is currently  
used. Of the other options, it does look like strict list-prefix  
matching is the least surprising, but also the least flexible.

-- 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.