On 10-Jun-1998, S. Alexander Jacobson <[EMAIL PROTECTED]> wrote:
> On Thu, 11 Jun 1998, Fergus Henderson wrote:
> > > It would make debugging easier if the exception picked was consistent
> > > accross implementations.  It doesn't matter which one, but it does matter
> > > that it is the same.  (maybe you require that Exceptions implement Ord, 
> > > or sort based on the Hashvalue of the constructor)
> > 
> > I think this would be difficult to implement efficiently.
> 
> Why is this difficult to implement efficiently?  If exceptions are strings
> (as they appear to be in Simon's initial proposal), then you can sort
> alphabetically.  If they have type, then they would be required to  
> implement Has_HashValue and the implementation could rely on existential
> types to sort.  I am sure there are better ways, but It is not obvious why
> the objection to cannonical ordering should be implementation
> efficiency...

Efficient implementations may be possible, I just don't think they are easy.

The problem is not the cost of the comparisons -- after all, that only
occurs in the exceptional case.  The problem I'm worried about is the code
size and run time cost of installing the handler in the first place.
For many common implementation models, every function such as `+' that
is strict in two or more arguments will need to install an exception handler.
This could be significant overhead, and furthermore it is overhead that
you will pay even if your program doesn't make use of exceptions.

Suppose, for argument's sake, that you are compiling to Java.
Then the code for integer plus might look something like this

        int plus(HaskellInt arg1, HaskellInt arg2) {
                try {
                        int arg1_val = arg1.eval();
                } catch (Exception e1) {
                        try {
                                int arg2_val = arg2.eval();
                        } catch (Exception e2) {
                                throw (e1 < e2) ? e1 : e2;
                        }
                        throw e1;
                }
                int arg2_val = arg2.eval();
                return arg1_val + arg2_val;
        }

whereas with the nondeterministic model the code could be just

        int plus(HaskellInt arg1, HaskellInt arg2) {
                int arg1_val = arg1.eval();
                int arg2_val = arg2.eval();
                return arg1_val + arg2_val;
        }

The latter will be cheaper, and the difference may be significant.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]        |     -- the last words of T. S. Garp.


Reply via email to