-
Notifications
You must be signed in to change notification settings - Fork 4
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
Use render
to implement an instance for Show
#13
Conversation
This refers to tfausak#12
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.
Thanks, this looks great!
All else being equal I would definitely prefer to keep all the stuff related to rendering in the render module. But I think this approach is the least of all evils. It's definitely better than orphan instances or .hs-boot
files 😄
@@ -28,7 +28,6 @@ | |||
-- In short, use @parse@ to parse templates and @expand@ to render them. | |||
module Burrito | |||
( Parse.parse | |||
, Render.render |
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 think we could keep exporting this as a type-restricted version of show
.
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.
Hmm, I don't think I got that. Could you explain that a little? What is the advantage of having render
in addition of show
?
Apart from that, I would just have to add render
to the exports of Burrito.Internal.Type.Template
to get what we want, right?
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.
One advantage is API stability. Since Burrito.render
currently exists, I would like to keep it there unless there's a compelling reason to remove it.
In general I like to have monomorphic versions of polymorphic functions since they can sometimes help with type inference. In this particular case it doesn't matter much since Burrito doesn't expose any polymorphic ways to create templates. But imagine if it implemented a Read
instance; then you could use render . read
to round-trip a template. The alternative would be something like show @Template . read
or show . (\ t -> t :: Template) . read
.
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.
That makes sense, thank you for the explanation! Should be done in the latest commit
Edit I'll fix the unnecessary whitespace changes as soon as I'm back at my laptop
Co-authored-by: Taylor Fausak <taylor@fausak.me>
Co-authored-by: Taylor Fausak <taylor@fausak.me>
I don't even know what Apart from the open suggestion with the export for |
This keeps `Burrito.render` in the public API
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.
Fantastic! This should make playing around with templates in GHCi a much nicer experience. Thank you!
One tiny little change: Could you keep the export list in the same order as before? The order in the code is the order that things show up in the documentation. I like showing parse
, then render
, then expand
.
Thank you! |
This is a first, naive solution for #12. (less naive than just putting an orphan instance in
Burrito.Internal.Render
).Baiscally I just moved the two functions in
Burrito.Internal.Render
that had a dependency toBurrito.Internal.Type.Template
over toBurrito.Internal.Type.Template
and fixed compile errors. The tests are green, andshow
does what I would expect.I'm not entirely convinced that this is a good solution. In terms of cohesion, the functions I moved should reside in
Render
. I just moved them over to avoid the cyclic dependency.What do you think about this?