-
Notifications
You must be signed in to change notification settings - Fork 0
Description
There's something that I'm not quite satisfied with with #26 (and #27, possibly) in the design of the Eval type class: it's all or nothing. It can be convenient, you can “just eval” when you don't care too much about what you're evaluating. It's a decent alternative to nf which may not require evaluating the whole type.
But Eval gives you no guidance when you want to combine strategies.
It's a little annoying, because there's a pattern: for most type T a1…an, eval is of the form
evalT (eval @a1) … (eval @an)(this is not profound, it's just saying that the instance is of the form instance (Eval a1, … , Evan an) => Eval (T a1…an))
I just feel that this evalT would be useful to expose. Is it possible? Certainly we could define it by hand with a conventional name everywhere. But this feels a little too inconvenient, maybe? Too easy to forget? That being said, there's probably no way that such an evalT would be derivable with Generic since Generic only operates on types of 0 or 1 argument.
A refinement would be to expose individual constructors. So that
evalEither eval_a eval_b = evalLeft eval_a <|> evalRight eval_bThis is interesting too (maybe even easier, actually), but I still think that evalEither ought to be provided.
I don't know exactly what I want of this. I'm trying to record my thoughts for the time being.