Quoting Jason Dagit <dagit@xxxxxxxxxxxxxxxxxxxx>:
> I was making an embedded domain specific language for excel
> spreadsheet formulas recently and found that making my formula
> datatype an instance of Num had huge pay offs.
Just so you know, what we're talking about here is a way to make that
even _more_ useful by dicing up Num.
> I can even use things like Prelude.sum to
> add up cells.
Ah, but the sum function only needs 0 and (+), so it doesn't need
the full power of Num. It'd be even _more_ useful if it worked on
all data types which supported 0 and (+), but not necessarily (*):
sum :: (AdditiveAbelianMonoid a) => [a] -> a
product :: (MultiplicativeAbelianMonoid a) => [a] -> a
Those are bad typeclass names, but you get the idea.
Right now, to reuse sum, people have to come up with fake
implementations for Num operations that simply don't make sense on
their data type, like signum on Complex numbers.
> All I really needed was to define Show and Num
> correctly, neither of which took much mental effort or coding tricks.
You also needed to derive Eq, which gives you, in your case, structural
equality rather than semantic equality (which is probably undecidable for
Haskell-Cafe mailing list