Allow error constructors to use named error type

[jclark]

This is the intermediate step between #67 and #2.

The main point is that if you specify the error detail string in the error type, you should not need to repeat it in the error constructor.

[jclark]

With this there are two kind of error constructor:

1. the kind we have now, using error
2. a new kind, which uses a user-defined type name referring to an error type instead of error

There are potentially three policies rules are regards the error reason argument: required, prohibited, optional. I believe our plan was to make it optional in both cases, but I think this is potentially confusing since it would have what is in effect an optional positional parameter, before a potentially required named parameter. So I would instead suggest a less flexible rule: make the error reason string required in the first case, and prohibited in the second case. This would mean that you can use the second kind only when the error type has a singleton error reason parameter.

[jclark]

Note this needs to work in binding patterns as well as expressions. The obvious semantics is that it matches if it belongs to the type. That raises to a point about the semantics of match #152 . We could separate this into a separate issue to do later.

[sanjiva]

I agree the current model is lacking clarity and simplicity.

+1 for a model where we say if you use the error() constructor you MUST give the reason string and that you CANNOT give it if use a particular type name as the constructor.

My only problem is that this further encroaches into establishing this as the way w.r.t. #2. I'm not happy about that :) but not sure what we can do right now (I will comment on that issue).

[sanjiva]

And I like the further restriction that the second kind is usable only when you have a singleton reason for that type. IMO we should encourage that - other than for binding patterns, I don't see unions of reasons being a good way to design errors.