Thus, pattern guards can be seen as addressing a similar goal to that of views, namely reconciling pattern matching with data abstraction. It is natural to ask whether views subsume pattern guards or vice versa. However, views give a view on a single value, whereas guards allow arbitrary function calls to combine in-scope values. We do not want a view of env nor of var1 but rather of their combination by lookup . Views simply do not help with clunky .
Views are capable of dealing with the data abstraction issue of course.
Here we can re-use the existing Maybe type. Not only does this save defining new types, but it allows the existing library of functions on Maybe types to be applied directly to the result of getFunTypeMaybe . The view version is undoubtedly more compact. When nested pattern guards are used, though, the use of a where clause fails. We can share the first call to absInt but not the second.