This is about how to continue the OO CA systems (like Axiom or DoCon).
Waldek Hebisch wrote
> Anyway, FriCAS categories have parameters which may be types or normal
> values -- my impression is that Haskell type classes only allow types as
> parameters.
Yes.
> In FriCAS parameters to categories itself have types.
> Both interface part (exported signatures) and implementation part may be
> conditioned on types of parameters. Parameters to types may be computed
> at runtime and effect of conditionals depends on actual type.
> In absence of conditionals type checking uses static information
> (given by categories), but for example in:
>
> f(a : A) : A ==
> if A has Field then 1/a
> else a
>
> when typechecking '1/a' typechecker knows that A is a Field
> (because we checked this in 'if'), so division is available.
> This type of conditional is used a lot in FriCAS algebra.
> [..]
Let us call the feature "dependent domains".
Due to the absense of dependent domains in Haskell, the DoCon library
applies the
sample argument approach (SA).
For the illustration, consider the example.
The polynomial representation (Pol mons vars ppo cDom)
contains the description (as a Haskell data) of the `argument' domain
cDom -- here this means the coefficient domain.
Domain is more than merely a type. A type is static, and it breaks
dynamically into domains.
A type T = Pol a together with a sample element
s = (Pol mons vars ppo cDom)
define a domain D = D(vars, ppo, cDom)
of polynomials. T is provided with the instances AddGroup, ..., Ring,
so that (+) and (*) and such, are accepted by the compiler for T --
the compiler understands this.
Also DoCon declares
instance Field a => EuclideanRing (Pol a) where
divRem f g = ...
And this means that
some domains in this type (Field a => Pol a) are Euclidean.
And detection of an Euclidean domain inside T is not by the compiler,
it is by the DoCon library implementation, it is (usually) at run-time.
dD = domain f = polDomain vars ppo cDom
builds the decsription of the polynomial domain from cDom and from the
parameters vars, ppo. vars, ppo, cDom are Haskell data (values).
polDomain ignores the monomial list mons, it uses f only as a
sample -- a holder of the parameters describing the polynomial domain.
Defining of whether D is Euclidean is by
isEuclidean (D vars ppo cDom) = (card vars) == 1 && isField cDom
This means
"iff there is a single variable and the coefficient domain is a Field".
isField cDom checks the value for IsField in the structure of cDom
(the static declarations like "instance ... => Field ..." are not
sufficient here).
Respectively the domain constructor for Pol sets the corresponding
value for IsEuclidean in a certain table in the description dD for
the polynomial domain. This is all processed at run-time.
Also
divRem f g = ... checks isField cDom for cDom of f,
if it is False, then breaks with the error message.
Otherwise, computes the quotient and remainder by the
Euclidean method for polynomials.
Now, suppose that f has vars = [x] and g has vars = [y].
divRem will break by "different domains", because it is easy to compare
the variable sets (at run time).
Suppose that f has cDom and g has cDom' /= cDom.
DoCon either needs to check this equality before starting to divide or
to impose this on the programmer (as I recall, DoCon does the second).
In the latter case, if the programmer erroneously mixes different domains
(in the same static type), the result may occur incorrect.
So, the static check part is safe, and half of the remaining check part
is on the programmer.
All this is expressed only in Haskell.
Similar are the domain constructors for Vector, Matrix, ResidueRing,
etc.
And for most constructors, each value also contains the description of
the argument domains.
A large part of DoCon constitute the functions which build and analyze
such domain descriptions.
This is explained more thoroughly in the DoCon manual.
Since about 1997, I am sure that this is the only way to program
mathematics in Haskell.
The Haskell community has rejected this approach -- the Basic Algebra
Library proposal (BAL). It was rejected in about 2000, somehow by
majority of votes.
I think this is because
(1) people (even mathematicians) are lazy to read the manual and understand,
(2) the approach is indeed complicated.
On the other hand, the alternative attempts also have been rejected.
And some mathematicians in the Haskell list have agreed with me that this
situation is due to the absence of the value-dependent instances in the
language.
Now, I started (with the help of your comments) to think that I understand,
in principle, what are the languages Axiom and Aldor, and what is the
current state of their project.
Generally,
How can the OO project for mathematics develop
----------------------------------------------
(my personal opinion)
1. The language must be functional (and even laziness is desirable),
somewhat as nice as Haskell, popular, with an open-source and reliable
implementation.
Personally, I would not program in Aldor, nor in Spad.
How to bring the value-dependent instances to Haskell ?
I do not know. Probably, this will be a very different language, with a
very different name.
I do not know of any person who is going to design a language of this kind.
The Qi (Shen) language can be a candidate. It has a particular and
powerful type system. But it needs to add classes, with appropriate
parameters, may be by the library, I do not know. Probably, this is not
so difficult. But the Shen developers currently are not going to deal with
this. I wrote them that without classes they loose many possible
applications. And decided to wait and to look there after an year or two.
There are the two ways to continue:
a) by the SA approach of DoCon (which I still like),
b) by an improved language -- when such is designed and implemented.
In both cases there remains the problem of the initial library:
even if the language is ideal, almost nobody will continue DoCon or
other system, if its initial set of mathematical methods is about 4%
of Axiom.
2. How to bring the library.
Now, if there exists an open-source Axiom version with a
free enough license,
then compile its library into C, join to DoCon and interface to Haskell
at the C level (Haskell provides some interface support for C).
And call this, say HaskAxiom, and reference to Axiom and Haskell in
the documentation.
>From this point on, the user enjoys both a large initial library and a
nice language to continue this library.
For example, consider (factor f) for f in k[x_1 ... x_n],
k a prime field (the current DoCon has such method only for n = 2).
(1) Convert f from DoCon to the Lisp representation of such f in Axiom,
(2) convert further to the representation g at the C level
(probably, GCL uses such),
(3) apply factor_of_Axiom(g),
(4) convert the result back to the DoCon (Haskell) data at the C level
(if there exists a Lisp intepreter written in C, then this may be easier
to arrange).
Apply a similar approach for various functions which are not in DoCon:
polynomial system solution, integration, limits, series, approximate
methods with float numbers, etc.
There are the following obstackles.
a) Does the license allow?
b) I never programmed the C interface from Haskell.
c) One needs to study and use in detail the Lisp representation for a
domain in Axiom. Such as for a prime field k, for a polynomial over k,
obtaining its C representation is more complex.
d) They say, there may be a disagreement in the usage of the GMP library
(for multiprecision integers) which is used in the GHC (Haskell) and,
probably, in GCL.
I do not know currently, whether this project is fantastic or not.
Just a strange idea.
Regards,
------
Sergei
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
