There is one issue here that I forgot to mention. Lenses really mess with
type errors, even if you always just use `view`. For example, here is a
type error one user got while using `view decoded`:
lpaste.net/99623
Specifically the user wrote something like this:
p1 >-> view decoded p2
The actual error was that `view decoded` returned a `Producer` and you
can't compose anything upstream of a `Producer`. I went to the trouble of
simplifying their error message using type synonyms to prove this:
http://lpaste.net/99627
You can basically read that simplified type error as saying "The `decoded`
lens should be returning a `Producer`, but the context expects a `Pipe`"..
The last type parameter of the `Getting` is what the `view` returns.
Had they used the non-lens equivalent of `decoded` (i.e. something like the
old `decodeGetMany`) they would gotten an improved type error. I put
together a small code example showing how just defining an `intermediate`
non-lens function improves type errors:
http://lpaste.net/99672
The issue here is that even if you always use `view` the lens abstraction
leaks into the type errors unless you define intermediate functions. This
is the main rationale for including non-lens versions of functions: to
improve type errors.
--
You received this message because you are subscribed to the Google Groups
"Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
