-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#97, make sure OneofSubfield generates well-typed code for non-Maybe #99
Conversation
|
||
xE <- (if isMaybe then id else fmap forceEmitE) | ||
. wrapE ctxt options dpType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using dimap
would be nice here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I don't see how to use dimap at all. Any hints?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, you're right -- I thought both the pre- and post- operations were enabled by isMaybe
.
This might read better though:
let adapt | isMaybe = lmap wrapJust
| otherwise = rmap (fmap forceEmitE)
xE <- adapt (wrapE ctxt options dpType) (HsVar (unqual_ "y"))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find that harder to read. I guess I'd usually (. wrapJust)
and (fmap forceEmitE .)
rather than lmap/rmap - and in this case I'm not sure it's clearer at all. But happy to go that way if you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking that it would be better to consolidate the adjustments predicated on isMaybe
, but on second thought the extra indirection obfuscates matters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 (with changes)
As an aside, I think generating
((Hs.coerce @(Hs.Int64)
@(HsProtobuf.ForceEmit (HsProtobuf.Signed (HsProtobuf.Fixed Hs.Int64))))
y)
would be even nicer, but there isn't really a performance benefit and would complicate the wrapE
machinery.
Thanks for the review. Yep, I tried to do that coerce you mention first, but that requires adding ForceEmit to the type data type, which seemed to be not very clean. |
Thanks for the bug fix, @ndmitchell! |
Before the test case in #97 generated:
Now it generates:
I'm assuming the ForceEmit is important, and that seemed like the only sensible place to put it. But I was totally guessing... I welcome feedback!