Hans Aberg:
> The thing is though that Haskell fixes the names of the symbols one can use
> in say a group. So if one cannot express a group as a quadruple (G, e, *,
> ^-1), then there is no way from the concept of a group to derive the
> concept of an Abelian group, and then by derivation saying that a ring is
> an Abelian group under addition.
>
> In fact this problem showed up in the posts a time ago where a fellow
> wanted to make a library with the usual symbols + *. The suggestion for
> solution was to rewrite the Prelude, otherwise it is not possible to do it
> in Haskell.
I believe that the statement "... express a group as" would acquire
a more constructive sense if we transformed it into "parametrize a group
by...".
The problem is that -- if you permit my timid excursion into the the
Holy Categoryland I know almost nothing about --
the FUNDAMENTAL, untouchable concept in all our common business is the
function application. So, Objects in Haskell may be variables: types may
(and do) parametrize functions. Morphisms - never! (Please don't tell
me that a->a is a type, I know that).
All the methods within a class are declared rigidly.
Operations within a class are not Objects (instances of).
The only place where we see a kind of parametrization in this induced
category is the concept of constructor classes. When I saw them for the
first time, I was enchanted. A piece of Heaven. But in fact it was
Purgatory (quite pleasant, but not as the final goal).
And, what is most funny - even the -
-may I say a bad word? Thank you.
even C++ permits that! It is possible to define a class with objects
which may act as functions through overloading of the () operation.
In principle it is possible to define a subclass of the multiplication
operator. I wonder whether - and how - it would be possible in a future
version of Haskell, but I cannot stop thinking about. You can do that
in Python as well. And in MuPAD.
==
This would not solve all the problems with mathematical hierarchies. It
does not suffice to inherit Ring from AdditiveGroup (+) and Monoid (*).
Any AdditiveGroup is a Module over integers, and a Ring is automatically
a Module over itself. There are subsumptions. A truly mathematical
language
should permit not only the subclassing, but also extensions.
All this has already been implemented, for example in Axiom (or Magma or
MuPAD), but in an opaque, dynamic, and probably not the most efficient
way.
In MuPAD a domain does not *belong* to a category, it *HAS* a category
as
its internal attribute which can be dynamically checked, but which does
not
optimize the compilation of expressions.
(Btw. everything can be "simulated", see e.g. the wonderful paper
on a categorical prelude by Erik Meijer and Luc Duponcheel: the
expressive
power of constructor classes. I wonder whether it was published
somewhere,
or it exists until now only as the Rijksuniversiteit Utrecht preprint,
1994.)
==
So, we are very far from such small problems as tickering with (+) or
(*). By the way, you don't need to rewrite the Prelude, you may just
screen it through <<Import hiding>>. I do it all the time (and I have
some unsolvable problems with Nums which seem to be hard coded within
the compiler, but I can live with it).
Thank you.
Jerzy Karczmarczuk
Caen, France.
