In my n+1 years of participating in a 100kloc Haskell project, I learned that programming with the "categorical" data type building blocks "Either" and tuples leads to code that is hard to read and maintain. It is tempting to use a pair type QNamed a = (QName, a) instead of a hand-rolled data type data QNamed a = QNamed { qname :: QName, qnamedThing :: a } since with pairs, I get lots of operations for free, and even more if I use Functor and Traversable, it seems. However, in the long run, if I come back after months to my original code, or even worse, to someone else's code, I dearly pay for this: 1. Harder to read the code, as I may only see the non-telling "fst" and "snd" instead of the semantics-loaden "qname" and "qnamedThing". 2. Lack of code exploration facilities like grep and tags. I can grep for "QName" and "qname", but grepping for "," and "fst" returns lots of irrelevant locations. 3. Non-telling error messages. And all the arguments of using newtypes over type synonyms apply here as well. So, my advice is to use tuples only for very short-lived data, like returning multiple results from a function. I am speaking here of Haskell as a language for software development, not of Haskell as a realization of category theory. For getting a broader acceptance of Haskell as a language for software development, Foldable on tuples is not helpful. And yes, if I was new to Haskell and learned the GHCI thinks that minimum (1,2) == 2 then I would advice GHCI to visit some mental institution to get its delusions fixed. --Andreas P.S.: I spoiled my pun in a previous version of this email. Thank God, my subconscious is not deluded yet. On 23.02.2016 18:29, Nathan Bouscal wrote:
Sorry, poor quoting on my part. I was attempting to reply to Andreas's earlier points:
Use of tuples is highly discourageable… I see no point in Functor or Foldable for tuples.
On Tue, Feb 23, 2016 at 5:18 PM, Mario Blažević <mblazevic@stilo.com <mailto:mblazevic@stilo.com>> wrote:
On 16-02-23 11:23 AM, Nathan Bouscal wrote:
It's a bit bold to simultaneously say "Nobody should use this type," and also "If you use this type, you should do it this way." If you think that it's bad practice to use tuples, that's a fine and respectable opinion, but at that point you should start being a bit more wary about telling those who think otherwise /how/ they should use them.
I believe he was referring to lists, not to tuples. There were few Prelude functions limited to tuples before FTP, and those haven't changed.
On Tue, Feb 23, 2016 at 1:10 PM, Marcin Mrotek <marcin.jan.mrotek@gmail.com <mailto:marcin.jan.mrotek@gmail.com> <mailto:marcin.jan.mrotek@gmail.com <mailto:marcin.jan.mrotek@gmail.com>>> wrote:
> I can assure you that Andreas is not delusional
I didn't say that. I was referring to his response to my post, that "Some delusions have very sophisticated explanations."
> You have to show good taste or you'll end up with a mess that might be logically consistent, but unpleasant to use.
This is entirely subjective, and frankly I don't think that post-FTP Haskell is a "mess" or is "unpleasant to use". If anything, it became more useful to me, because now Prelude functions aren't limited to the one data structure I almost never use.
Best regards, Marcin Mrotek
_______________________________________________ Libraries mailing list Libraries@haskell.org <mailto:Libraries@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/