On Sat, Nov 12, 2011 at 05:28:07PM +0100, Waldek Hebisch wrote:
> Serge D. Mechveliani wrote:
> >
> > This is about how to continue the OO CA systems (like Axiom or DoCon).
> > [..]
> I am not sure what problems you have with Spad.
I highly respect the Axiom library.
I respect Spad and Aldor: they have a considerable extension over Haskell
in their type classes and instances. Probably, they are nicely implemented
-- OK.
But today there are many users who cannot imagine themself programming
mathematics in a non-functional language. And I am one of them.
Also I hardly can imagine myself programming in a strict language
(there also may be some minor points of the code nicety, sugar).
Somehow a matter of taste. One likes to smoke in a train, and other one
suffers in a vagon with smoke.
Besides taste, I could give explanations of why FP is good, scientific etc.
But I guess, this discussion is of a too general spirit, it is not for
this e-mail list. Let me be more definite.
This community needs somehow the "Axiom library for functional use",
"Axiom library for Haskell-like use".
And they are lazy to develop a large initial library themself
(say, 80 man-years of work).
> 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.
I have read about Shen. And could not understand, how a Qi program can
be reasonably compiled, for example, into Haskell.
But now, after your note, I am doing one more attempt to understand this
-- with respect to Axiom.
(1) The GHC Haskell kernel is a certain virtual machine HM which
runs a code represented as supercombinator expressions etc.,
by a certain graph rewriting method, or such
(there are a book and certain papers about this).
It is compiled to C, but the GHC team wrote about explicit fixing
of this HM level, and I believe, we can use this level.
Further, it is for the "lazy" computation by default.
But Haskell also allows certain strictness annotation.
And I hope that if in the code it is set everywhere the strictness
annotation, then this code computes strictly by HM.
This makes possible to compile from Lisp to HM.
(2) The Axiom library also exists in the form of a certain Lisp-like
code (?). Denote it AxiLibLisp.
(3) Someone writes a compiler from this Lisp-like to HM,
with setting the strictness annotation everywhere
(one needs to know Lisp-like and HM in detail).
Applying this compiler produces the code AxiLibHM of the Axiom
library for the HM machine of the GHC implementation for Haskell.
Is this your idea?
Do you say that this way of porting of the Axiom library is more
realistic than via the C code?
Idea-2: the first experience may be
to write the Lisp-like interpreter in Haskell and to join the code
AxiLibLisp as the Haskell data to the Haskell program.
It will run slower, but it is easier to arrange than (1)-(3).
(?)
Regards,
------
Sergei
[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.
