Make unmodular code generation a bit more unmodular#4233
Make unmodular code generation a bit more unmodular#4233
Conversation
balacij
requested review from
JacquesCarette,
bmaclach,
samm82 and
smiths
as code owners
|
@balacij, this change should be helpful when we return to the human-readable code paper. |
|
We want as broad a choice of "code families" as possible. So we should have ways to tune things, hopefully with somewhat fine-grained precision. So these changes should not remove previous possibilities, but augment them. So we need sub-choices of |
| -- | Program implementation options. | ||
| data ImplementationType = Library -- ^ Generated code does not include Controller. | ||
| | Program -- ^ Generated code includes Controller. | ||
| deriving Eq |
There was a problem hiding this comment.
We've tended to avoid deriving Eq (even though in this case it is completely harmless) to emphasize a pattern-matching style over a "boolean" style. Why do you need Eq?
There was a problem hiding this comment.
I can actually remove this now -- I previously was avoiding a very small case statement in genMainFunc but I've since changed it back to a case statement.
| | otherwise = [genInputFormat Pub, genInputDerived Pub, genInputConstraints Pub] | ||
|
|
||
| modFuncs :: OOProg r => [GenState (Maybe (SMethod r))] | ||
| modFuncs = map (fmap Just) $ concatMap genModFuncs (modules g) |
There was a problem hiding this comment.
This is an odd piece of code -- it deserves a comment!
| return 0; | ||
| } | ||
|
|
||
| double func_t_flight(InputParameters &inParams) { |
There was a problem hiding this comment.
while I'm completely fine with the logging of the inline version being much less verbose, we shouldn't lose quite so much logging. Issue six?
|
|
||
| }; | ||
|
|
||
| /** \brief Calculates flight duration: the time when the projectile lands (s) |
There was a problem hiding this comment.
When comments are turned on, I think a version of these comments should go above the inlined code.
| double p_land = func_p_land(v_launch, theta, g); | ||
| double d_offset = func_d_offset(p_target, p_land); | ||
| string s = func_s(p_target, epsilon, d_offset); | ||
| // flight duration: the time when the projectile lands (s) |
There was a problem hiding this comment.
Why have the comments started appearing here? [Don't get me wrong, this is a great option to have!] But we should have a version without them too.
There was a problem hiding this comment.
When comments are turned on, I think a version of these comments should go above the inlined code.
These are meant to be the inlined code comments. It's just a weaker variation of the ones that would go above the function-generating counterpart. I don't think we want the full commentary, do we?
There was a problem hiding this comment.
Correct, not full commentary, thus my "a version of".
| data Comments = CommentFunc -- ^ Function/method-level comments. | ||
| | CommentClass -- ^ Class-level comments. | ||
| | CommentMod -- ^ File/Module-level comments. | ||
| | CommentVarDecls -- ^ Variable declarations comments. |
|
Converting to Draft because it needs to:
|
|
@JacquesCarette and I discussed this in our meeting yesterday. Paraphrasing our discussion:
|
3 participants
Contributes to #1999, #3247, #3512
Not quite ready to merge yet, but, this PR makes the
Unmodularcode generation choice a bit more unmodular by removing the generated function calls in favour of inlining them.ThreeFourFive major issues:GProc-generating code is untouched.I'm also not quite sure yet how we should integrate this in the options. Should these changes go under Unmodular? SuperUnmodular? SpaghettiMonster? I currently have it editing
Unmodular.