5 ms·

The identity element of the conjunction (“and”) monoid is True. Any confusion here seems like a good reason we should teach students functional programming - th

• eru 7y ago
  I'm in your camp. But the best argument I found is: "This is a confusing situation, and no boolean answer we could give would satisfy the principle of least surprise, so we should throw an error." I don't think there's a good argument to be made for returning False. As an aside: I don't think there's anything particularly related to 'functional programming' about the arguments used here. But, yet, experience with functional programming tends to make people more careful about finding general principles that give you answers for corner cases like this, too. The imperative code used in the Python standard library is just as compelling an argument for the Right Answer also being the simplest as any based in FP: def all(iterable): for element in iterable: if not element: return False return True In general, when I'm reviewing imperative code, I'm encouraging the authors to find ways to handle corner cases like empty lists organically within their code instead of with a special case check at the top. The organic handling seems to have a higher chance of producing the Right Answer.
  • wyager 7y ago
    > no boolean answer we could give would satisfy the principle of least surprise I think True follows the principle of least surprise. > I don't think there's anything particularly related to 'functional programming' about the arguments used here It imparts a better understanding of algebraic abstractions, including what it means to recursively reduce a data structure. I'm not sure how that python code is supposed to be especially simple or elucidating. I think the following Haskell code is reasonably elucidating, since it elides any need to manually define a special case or base case: all = getAll . foldMap All Where "All" is the conjunction ("and") monoid, as defined in Data.Monoid.
    • eru 7y ago
      > I think True follows the principle of least surprise. Me too. I was just quoting the best argument (I found so far) for a different position. > I'm not sure how that python code is supposed to be especially simple or elucidating. I think the following Haskell code is reasonably elucidating, since it elides any need to manually define a special case or base case: The Python code wasn't for comparison to any Haskell implementation. If you can read Haskell, you'll likely prefer the Haskell version. But that's not the point. The point is that amongst all imperative attempts, the most straightforward ones also naturally suggest what to do about the empty list. Btw, in Haskell notation most normal people's mental model of how 'all' works is probably closer to: all = foldl1 (&&) Most normal people don't think about neutral elements of operations, and that they suggest a natural answer for folds over empty collections.
  • pwdisswordfish2 7y ago
    > "This is a confusing situation, and no boolean answer we could give would satisfy the principle of least surprise, so we should throw an error." Common folk tend to disagree about whether zero is an even number. Calculating 0 mod 2 is a confusing situation, and no numeric answer we could give would satisfy the principle of least surprise, so we should throw an error.
    • eru 7y ago
      Indeed. I didn't say the argument was a good one. Just that it was the best I found.