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_b
This 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.
There's something that I'm not quite satisfied with with #26 (and #27, possibly) in the design of the
Evaltype class: it's all or nothing. It can be convenient, you can “justeval” when you don't care too much about what you're evaluating. It's a decent alternative tonfwhich may not require evaluating the whole type.But
Evalgives 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,evalis of the form(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
evalTwould 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 anevalTwould be derivable withGenericsinceGenericonly operates on types of 0 or 1 argument.A refinement would be to expose individual constructors. So that
This is interesting too (maybe even easier, actually), but I still think that
evalEitherought to be provided.I don't know exactly what I want of this. I'm trying to record my thoughts for the time being.