Closed erikd closed 10 years ago
Off the top of my head, isn't keyE = val . unValue
a valid definition for this problem?
Wow, yes, your version works correctly too (both giving the correct results and give a type error where it should).
However, the resulting function is much more general and the keyE
name no longer makes sense.
Any suggestions for a name? Or a description of what it does? I'm pretty sure I don't actually understand what its doing.
It's almost val
, but for something that is a Value
already. Perhaps valJ
with J
for join
? Naming's too damn hard :).
Still doesn't explain what its actually doing. If I had an understanding of that, I might be better able to name it.
I've updated the PR renaming it to valJ and improving the documentation.
Felipe, I can rebase those two commits into a single one if you'd like.
Thanks, no worries about rebasing! Released as esqueleto-1.4.2
.
Given a value,
keyE
lifts theKey
for that value into the query expression.This function (not totally happy with the name) solves a particular problem I met in my code base. I have a function
unValueKey
like this:and some times in a
where_
clause I would do:The problem is the composition of
valkey
withunValueKey
. Given this function composition, GHC infers a type of:which does not constrain the
entity
type parameter of the output to be the same as the input. Without that constraint, the above is non-sensical.To fix this, the type signature of
keyE
requires that input and outputentity
type paramer are identical.I would have added a test, but I really don't think this can go wrong :-).