hakaru
hakaru copied to clipboard
Improve pretty printing of if statements
This is being split off from @wrengr comment in #27
- [ ] When encountering
case b of { True -> e1; False -> e2 }
instead printif_ b e1 e2
. N.B., this should be sure to handle all cases where the scrutinee is ofHBool
type, including when the patterns may be given in the other order, when one pattern may be a wildcard or a variable, etc. - [ ] As a special case, when encountering
if_ b m reject
instead pretty print asguard b; m
so as to avoid excessive indentation
@zaxtax how did you make the ticky boxes?
If you type in - [ ] they appear On 8 Jul 2016 00:34, "wren romano" [email protected] wrote:
@zaxtax https://github.com/zaxtax how did you make the ticky boxes?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hakaru-dev/hakaru/issues/28#issuecomment-231272832, or mute the thread https://github.com/notifications/unsubscribe/AAAhUcNEGRMFXKuYwlcmvx-bfRrfhzbCks5qTdNkgaJpZM4JFKLi .
@zaxtax Is this still live?
Still worth doing, not urgent.
On Sun, Apr 16, 2017 at 6:12 PM, Jacques Carette [email protected] wrote:
@zaxtax https://github.com/zaxtax Is this still live?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hakaru-dev/hakaru/issues/28#issuecomment-294377280, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAhUWP7M8v_NB-SwJKS-P8Zxh7yqRdSks5rwpI-gaJpZM4JFKLi .
Did this maybe get done by either @ccshan or @yuriy0 when lots of changes to the parser and pretty-printer were done?
The first point is partially done. The yet-uncompleted portion:
this should be sure to handle all cases where the scrutinee is of HBool type, including when the patterns may be given in the other order, when one pattern may be a wildcard or a variable, etc.
it only handles match b: true: <t>; false: <f>
(not other orders, not wildcard or variable patterns).
The second point is not implemented.
I agree with @yuriy0's assessment.
Regarding the first point, if we want pretty-printing followed by parsing to be the identity, then we shouldn't implement the rest of the first point, because case b of { True -> e1; False -> e2 }
and case b of { False -> e2; _ -> e1 }
are not the same terms (i.e., not the same ASTs).
Regarding the second point, of course if we ever add guard
(and factor
?) to the pretty-printer then we should change the parser accordingly.
The conclusion might be that this is, in fact, not an 'issue' that requires action? If it is never going to be implemented, we should just close it.
It would be a welcome improvement to add guard
and/or factor
to our concrete syntax, and it's not too hard to implement, just not urgent.