"Brian Hulley"
Jón Fairbairn wrote:
[1] “-” is a varsym. The logical way of achieving what you suggest (ie -1 -2... as constructors for Integer) would be to make it introduce a consym the way “:” does, but then it couldn't be an infix operator anymore.
I don't think it's necessary to use the same kind of rule for '-' as for ':'.
Not necessary, but you surely don't want yet another rule?
I imagine that almost every editor at least does lexical fontification, and if so, then I don't think there could be much confusion in practice between these uses of '-'.
I think that unnecessarily disadvantages people with poorer than average (including zero) eyesight.
Yes, a typeclass for exp would be ideal
Well, so long as you call it “exponent” or “expt”.
(and a newtype for Natural).
Here's a design principle for you: if an error can be detected at compile time, it should be. If we have literals for naturals and not negative integers, “negate 100” causes no problem, it just means “negate (fromNatural 100)”. If we have literals for integers and try to restrict them to get naturals, “-100:: Natural” becomes shorthand for “integralToNatural (-100)”, and would (in the absence of somewhat arbitrary special-casing in the compiler) give a runtime error.
I also agree with Tamas's suggestion that an empirical analysis of Haskell source code could be useful to determine the practical implications of unary minus,
It has merit and I would laud anyone who got round to doing it, but there's a danger of measuring the wrong thing. What we want to know is not what is more frequent, but what causes the greater number of misreadings and which pieces of code had the most syntax errors before they were completed, and that's harder to measure. Though if unary minus turned out to be very rare, we could just drop it. Using “(0-)” wouldn't be much of a hardship in that case.
Anyway no doubt I've posted enough emails about unary minus and negative literals so I'll be quiet now ;-)
:-) ... ? -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk