-
Notifications
You must be signed in to change notification settings - Fork 205
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
Refactor damldocs -- turn types into newtypes #1883
Conversation
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 like newtypes, thanks!
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.
Good stuff, thanks!
, indent 2 (fieldTable cd_fields) | ||
] | ||
[ prefix "* " $ asCode (unTypename cd_name) | ||
, maybe " " (flip T.snoc '\n' . indent 2 . unDocText) cd_descr |
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.
👍 indentation added. Makes sense.
[ " : " | ||
, maybe "" ((<> " => ") . type2rst) fct_context | ||
, maybe "" ((<> "\n\n") . type2rst) fct_type | ||
-- FIXME: when would a function not have a type? |
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.
Functions could have no (explicitly-stated) type but a doc comment.
(as long as we still use the parser AST... the type checker will give every function a type)
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.
Ah, makes sense! We should probably switch to typechecker AST like you were saying.
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.
Maybe worth replacing the FIXME
s by explanations?
, prefix " - " $ type2rst fd_type | ||
, prefix " - " $ maybe " " (markdownToRst . T.unwords . T.lines) fd_descr ] | ||
, prefix " - " $ maybe " " (docTextToRst . DocText . T.unwords . T.lines . unDocText) fd_descr ] -- FIXME: this makes no sense |
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 construction unwords . lines
might seem funny... the idea was to ensure the documentation text is a single line. Otherwise we need to indent it correctly, which is a bit fiddly.
However, it might be better to do that. As a principle, we should retain the line breaks in doc.text over multiple lines. More important for doc.s on modules and top-level declarations, though.
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.
Yeah, makes sense. I was thinking of introducing an intermediate representation in Render.RST (and Render.Markdown which has the same problems) to make it easier to indent things correctly. Some kind of "rendered doc" IR that can be converted to Rst or Markdown easily. Because right now there's a lot of duplication between the output modes of damldoc, and the same issues cropping up over and over again.
Renamed
Markdown
type toDocText
(to avoid confusion with theMarkdown
constructor in Render.hs). Use newtypes forDocText
,Fieldname
,Typename
andModulename
, instead of representing all these different types of text as type aliases ofText
. Refactored some functions and deduplicated some code as well. The goal was not to change the output, only the code.But I did find one bug in the process, which I fixed: module descriptions were being returned as Rst without conversion from Markdown first.