This is interesting because it seems to be a counterexample to the claim that you can lift any Num through an Applicative (ZipList, in this case). It seems like maybe that only works in general for monoids instead of rings? On Mar 25, 2012 8:43 PM, "Chris Smith" <cdsm...@gmail.com> wrote:
> Jerzy Karczmarczuk <jerzy.karczmarc...@unicaen.fr> wrote: > > Le 26/03/2012 01:51, Chris Smith a écrit : > > > >> instance (Num a) => Num [a] where > >> xs + ys = zipWith (+) xs ys > >> > >> You can do this in the sense that it's legal Haskell... but it is a bad > idea [...] > > > It MIGHT be a ring or not. The "real problem" is that one should not > confuse > > structural and algebraic (in the "classical" sense) properties of your > > objects. > > Of course there are rings for which it's possible to represent the > elements as lists. Nevertheless, there is definitely not one that > defines (+) = zipWith (+), as did the one I was responding to. By the > time you get a ring structure back by some *other* set of rules, > particularly for multiplication, the result will so clearly not be > anything like a general Num instance for lists that it's silly to even > be having this discussion. > > -- > Chris Smith > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
