Polymorphic `if` statement

Learn
#21

afaict it’s exactly the same, you reuse syntax sugar for a different desugaring. e.g. if you do

import MyEDSL qualified as E

smth = E.do 
  statement 
  anotherStatement

This will exactly require the operators that this is desugared to, namely >>

#22

This is worse than RebindableSyntax in terms of UI

#23

What about (assuming we have a Boolish class)

ifte :: Boolish a => a -> b -> b -> b
ifte test then_ else_ = if (toBool test) then then_ else else_

Using ArgumendDo

ifte shouldShow
   do ...
   do ...
#24

The biggest pain point is having to enable RebindableSyntax, which is quite heavy. Something like QualifiedIf might be nice, although it would be a lot more niche than QualifiedDo.

#25

Personally I prefer the former, and in fact, given that case is so lightweight and \case is even more lightweight, I’d be willing to use a language that doesn’t have if at all! I don’t strongly see the point of if cond then e1 else e2 when case cond of True -> e1; False -> e2 is available.

2 Likes
#26

two possible solutions:

First: type alias

type ShouldShow = Bool

I guess it’s self explanatory. Of course it allows the use of if and so on. The way you named the type, ShouldShow, there is no confusion what True and False represent and you are about to reimplement Bool, anyway.

Second: don’t use if

This is how I actually do stuff:

data ShowHide
  = Show
  | Hide

More verbose and explicit alternative:

data Visibility
  = VisibilityShow
  | VisibilityHide

Of course, both of them allow to add a third value at any time, e.g. for a blocking and a collapsing version of a hidden state.

And I don’t usually see a problem with the resulting

case visibility of
  VisibilityShow -> ...
  VisibilityHide -> ...

My personal choice

My dirty secret: I even use case on bool types because if results in line breaks and white space that interrupt the flow (my subjective view). case is just so much clearer and more flexible at the same time.

Because of my dirty secret your initial problem/challenge turns out to be none. Avoid boolean blindness, prefer case over if strictly, have elegant and flexible code.

3 Likes