Serge D. Mechveliani wrote: > > This is about how to continue the OO CA systems (like Axiom or DoCon). > ... > 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.
I am not sure what problems you have with Spad. My point of view is that Spad compiler is relatively small translator (plus runtime support) targeting a virtual machine. Currently this virtual machine is a tiny layer on Common Lisp. But it uses only a subset of features of Common Lisp and could be retargeted. Note that Shen project is about retargeting Qi (which was Common Lisp only) to different virtual machines. Retargeting Spad may be harder, but I do not think it is much harder. > 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? Sure, Axiom/FriCAS uses new BSD licence -- you can do almost anything except for claiming that you wrote it. > 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. > Some problems that you will hit: 1) Uncooprative garbage collectors: you have two sides using different garbage collectors. If one side keeps reference to something on the other side the others side should keep it even if it would be garbage otherwise. If the first side drops reference the second should garbage collect the item. Tricky, unless you limit exchange by for example creating copies of everything. But for lazy potentially infinite structures, like streams copying is tricky. 2) Presumably you want nice types on Haskell side. So you will need to build type hierarchy mirroring Axiom types. But that is tricky, since typesystems on both sides work differently. 3) In some cases converting adds only little overhead. But in other cases it may essentially kill performance. Sage performs much of it computations via external programs or libraries. In several cases they realized that they need to keep data in format native to foreign library, otherwise conversion costs are too big. 4) For Axiom data you need to know its type to make sense of lower level representation (types are _not_ part of values). > 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. > > -- Waldek Hebisch [email protected] -- 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.
