Hmm.. this misses one of the major advantages of views IMHO, pattern synonyms, which would let you seamlessly upgrade interfaces to ADTs, which at the moment is cumbersome, you either have to plan from the beginning and use functions instead of pattern matching or create a new, incompatable API. in a few cases, records can also be used. so, oddly enough, the views subset I wanted to see would be something like this
data Term = Var String | Terms [Term] where EmptyTerm = Terms []
now, EmptyTerm can be used in pattern matching and as a normal constructor. The restrictions to the RHS of such declaraions are straightforward, the arguments must be valid, no variables may appear free. irrefutable patterns would be allowed, they would have no effect when using the alias as a constructor, but would have their normal meaning when used as a pattern match. in addition '_' would be allowed, having its normal meaning when used as a pattern match, but becoming 'undefined' when used as a constructor. perhaps this is unrelated to views, but this sort of thing is what I found attractive about the old proposal. John -- John Meacham - ⑆repetae.net⑆john⑈