In hoc signo vinces (Was: Revamping the numeric classes)

[Jerzy Karczmarczuk]

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