In hoc signo vinces (Was: Revamping the numeric classes)
Mon, 12 Feb 2001 13:10:22 +0000
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
thereof. I don't want any automatic lifting nor *constrain* the Prelude
class. I want to be *able* to define mathematical operations upon
which by their intrinsic nature permit so!
My goodness, I suspect really that despite plenty of opinions you
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