3 ms·

This works fine, it just suffers from boolean blindness.

• dllthomas 12y ago
  Could you elaborate? I think I understand "boolean blindness" but I'm not sure how it applies here. MaybeFoo.type is deliberately an enum. (I could totally be missing/misunderstanding something, though...)
  • tel 12y ago
    Checking whether mf.type is NOTHING or JUST is your boolean. It's linked by providence to whether or not getFoo() is a runtime exception. With a true ADT getFoo would not be accessible unless mf.type == JUST, but in this example it's up to the programmer to enforce that providence. So that's the blindness. The pre/post conditions around how mf.type relates to its surroundings cannot be expressed first-class in the code. You are required to do risky things like call potentially partial code.
    • dllthomas 12y ago
      So it's specifically the separation of the check and the action? I totally agree this is undesirable; I understood "boolean blindness" to be closer to "bare primitive types lack meaning", specialized to Bool.
      • tel 12y ago
        I always think of it as your data types being too unrestricted so as to allow for invalid states. The eliminator for Maybe (a -> r) -> r -> Maybe a -> r means you only access the `a` if it's there and the access/matching are inextricably linked. So, I think "bare primitive types lack meaning" is basically correct given that you interpret "meaning" as "meaningful uses/actions".
        • dllthomas 12y ago
          Yeah, given the nature of the types involved here, I think the two concepts I was trying to distinguish are not as far apart as I'd thought.