Marcin Kowalczyk wrote:
Jerzy Karczmarczuk wrote:
I not only feel the need, but I feel that this is important that the additive structure in the codomain is inherited by functions.
It could support only the basic arithmetic. It would not automatically lift an expression which uses (>) and if. It would be inconsistent to provide a shortcut for a specific case, where generally it must be explicitly lifted anyway. Note that it does make sense to lift (>) and if, only the type system does not permit it implicitly because a type is fixed to Bool.
Lifting is so easy to do manually that I would definitely not constrain the whole Prelude class system only to have convenient lifting of basic arithmetic. When it happens that an instance of an otherwise sane class for functions makes sense, then OK, but nothing more.
Sorry for quoting in extenso the full posting just to say: I haven't the slightest idea what are you talking about. -- but I want to avoid partial quotations and misunderstandings resulting thereof. I don't want any automatic lifting nor *constrain* the Prelude class. I want to be *able* to define mathematical operations upon objects which by their intrinsic nature permit so! My goodness, I suspect really that despite plenty of opinions you express every day on this list you didn't really try to program something in Haskell IN A MATHEMATICALLY NON-TRIVIAL CONTEXT. I defined hundred times some special functions to add lists or records, to multiply a tree by a scalar (btw.: Jón Fairbarn proposes (.*), I have in principle nothing against, but these operators is used elsewhere, in other languages, CAML and Matlab; I use (*>) ). I am fed up with solutions ad hoc, knowing that correct mathematical hierarchies permit to inherit plenty of subsumptions, e.g. the fact that x+x exists implies 2*x. Thank you for reminding me that manual lifting is easy. In fact, everything is easy. Type-checking as well. Let's go back to assembler. Jerzy Karczmarczuk