On 2 Apr 2008, at 14:27, jerzy.karczmarczuk@info.unicaen.fr wrote:
That is possible, of course - I did that, too. But it means that the syntax and semantics do not work together; an invitation to pitfalls. So this ought to be avoided, except if there are no other workarounds.
I am more tolerant.
The pragmatics is to decide whether to program Haskell, or making a new language. I am interested in the latter, but realistically nobody will singly be able prdocue the programingg capacity that the now mature Haskell has.
The question - for me - is not an interplay between syntax and semantics, ...
That interplay, between notation and notions, is very important in math, as if the do not flow together, one will not be able to describe very complex logical structures.
...syntax here is irrelevant, the fact that (+) is a popular infix operator plays no role. The calamity comes from the fact that it is not possible to write serious and "natural" instances of Eq and Show for functions, ...
A correct Eq would require a theorem prover. Show could be implemented by writing out the function closures, but I think the reason it is not there is that it would create overhead in compiled code.
...and that for God knows which reasons, the Num instance demands them ! This requirement is not rational, although intuitive.
Probably pragmatics. More general implementations were not considered at the time.
But I violated it several times, when I needed arithmetic for lazy infinite objects... So, I can't say that this should be avoided. I don't see "obvious" pitfalls therein.
The pitfall is when somebody which does not know the code well tries to use it. Define a library with false = True true = False Perfectly logical, but it will be thwarted by peoples expectations.
It would be better to write a new Prelude. :-)
Oh, yes, our common dream...
Such changes will require a new standard. Haskell seems rather fixed, so it will perhaps then happen in a new language. :-) Hans