Exceptions

[Andres Loeh]

Hi Ashley.

Thanks for your interest in open data types. As one of the authors of
the "open data types" paper, I'd like to comment on the current
discussion.

You comment Simon's upcoming HW paper on extensible exceptions:

> You write:
> 
> > Compared to our approach, theirs requires new extensions to the language 
> > (although not deep),
> 
> "Typeable" is an extension to Haskell, and a rather ugly one at that. 
> The open datatypes extension is both cleaner and more general.

I think the stress here is on *new* extensions. I agree that an open
type of type representations might be a more beautiful solution to the
problem that Typeable solves. Nevertheless, the fact is that Simon's
solution can be used in current GHC without further implementation work.

> > and has difficulties with separate compilation.
> 
> They claim to solve this I think, though I haven't examined it really 
> carefully. You may know better, of course.

I've discussed this with Simon PJ. Apart from minor technical problems,
everything seems doable in GHC, but it is quite some work and it's not clear
that I will have the time to study GHC closely enough to do it in the
near future. I hope I can say more after the Hackathon ...

> > Arguably the open data types approach is more direct and more accessible,
> 
> Yes,
> 
> > as is often the case with extensions designed to solve a particular problem.
> 
> That's not fair. Open datatypes have other applications. A general "file 
> interpreter" for instance, that given a MIME type string and a list of 
> bytes yields an object. Or a collection of variable "resources" of 
> various types that could be passed to a program. Or a hierarchy of UI 
> widgets. Or anything that Typeable and Dynamic are currently used for, 
> but more cleanly. Hs-plugins, for instance.
> 
> It's the missing piece.

True, open data types have never been invented as a solution to the
problem of extensible exceptions. It is an application that we found
afterwards.

> > Still, the argument for adding open data types to the language is weakened by 
> > the fact that they are subsumed by type classes: in fact the authors give an 
> > encoding of open data types into type classes,
> 
> Well not really. The "encoding" involves lifting everything from values 
> to types, which means a function still can't return a value of an open 
> type determined at run-time.

Even if both approaches would be equally expressive, the type class encoding
still has a lot of syntactic overhead. Moving from a closed to an open data
type encoded by type classes requires changing your whole program, whereas
with open data types, it is a local change.

Apart from this discussion however, open data types are clearly not
Haskell' material, because the proposal is new and currently
unimplemented.

The extensions required for Simon's approach to exceptions have a good
chance of being included in Haskell'.

Cheers,
  Andres