This is kind of pedestrian for a mathematician, and there aren't any features in use here that are exclusive to Haskell. Basically, you're just definining a new field of numbers where you throw in the sqrt(5) into the rational numbers. You could very easily do this in Python too:
The only reason I haven't actually implemented a number type like this in Perl 6 (someone proposed it to me years ago) is I didn't really it had such a lovely and practical application.
Ture, but notice how easy and natural it is in Haskell. You can do the same thing in Python, as noted in the comment by jordigh -- but it takes ~40 lines, as opposed to ~8 lines in Haskell. I'm willing to bet that it's even more verbose in C++, and I don't even want to think about doing it in Java.
I aimed for clarity and some extra features in mine (e.g. __repr__ and __str__) instead of code golfing it. I also used the actual Binet formula instead of just approximation.
The only big Haskell feature here is a default implementation of binary exponentiation, but this is a library feature, not an innate feature of the language. It would be easy enough to augment existing standard Python libraries with such a corresponding feature.
It wasn't meant to be a criticism of your implementation - just a comparison of the two languages for this particular task. Haskell happens to be very concise for writing mathematical code. I love Python too, but for different reasons (easy to prototype, great libraries, flexible).
I've noticed that people with a mathematical background tend to be very attracted to Haskell. There's a great blog post by Dan Piponi enumerating eleven reasons to use Haskell as a mathematician:
I have a mathematical background, and I am not that attracted to Haskell. And I've tried. It seems that Haskell attracts logicians, which are their own particular subspecies of mathematicians, but I think far more mainstream mathematicians are attracted to Python. Sage is a prominent example of how easy it is for mathematicians to get into Python.
In fact, it encodes the same information given by your __str__ with the added benefit that it can be read back into a Q5 value:
1/2 + 1/2 sqrt(5)
Of course, yours would be nicer to display to someone unfamiliar with Haskell's type constructors. No arguing that. But it's also clear that Haskell's derived show trumps Python's default __str__/__repr__.