Date sent: Fri, 26 Nov 1999 13:06:08 +0000
From: Jerzy Karczmarczuk <[EMAIL PROTECTED]>
Organization: University of Caen, France
Copies to: [EMAIL PROTECTED]
Subject: Scientific uses of Haskell?
I have long been interested in Computer Algebra systems, and I
admit that one of the things that attracted me to Haskell were the
tantalizing hints that it would be ideal for mathematical
programming.
> Eduardo Costa:
>
> > With a little make up, things
> > like Zermello-Frankel notation would give a good replacement
> > for SQL. A good computer algebra library (like the one that
> > prof. R. Malaquias is creating) would make Haskell a good
> > scripting language to replace things like Mathlab, Maple, etc.
> > I really think that it is possible to lure a software company
> > into investing in Haskell.
> >
> > You could say that it would be better to have groups
> > of voluntary programmers (like the people who created Linux
> > and GNU), instead of companies like Microsoft. Well, I guess
> > that Haskell has atractive features to these groups too. For instance,
> > Haskell could be used to produce a free version of Maple,
> > Matlab, or even Labview.
>
> The problem is that no, even a particularly nice *notation* can
> replace the existing heap of applications, scripts, etc. It is
> not the functional notation which pushed me towards this domain,
> but the clean and powerful semantics of functional languages.
Would it also be true to say that FP offers the possibilty of
implementing more mathematically rigorous 'proof' systems as
well?
> So, I don't understand at all the idea to use Haskell as 'scripting'
> language. It might be a very nice *implementation* language for all
> kind of scientific computation packages, especially those who
> need an elaborate memory management schemes, or tortuous algorithms.
> For the moment it is less adapted to the psyche of this community
> (physicists, engineers, etc.) as the interface language.
>
> Do you know what makes Maple so attractive for newbies, for teachers,
> etc? One of the reasons is simply scandalous, awful, unbelievably
> silly : the lack of distinction between a symbolic indeterminate,
> and the program variable. You write ... f(x) ... and if x has not
> been previously assigned, you get 'x'. Computer algebra packages are
> - from the programming discipline perspective - monsters. You won't
> try to do things like that, in Haskell, ML, or anything reasonable.
>
> Or, change drastically the user habitudes...
>
> Reimplementing a computer algebra system, why not? Sergey Mechveliani
> works for some years on computer algebra library. I play with some
> lazy algorithms on mathematical structures trying to avoid "symbols"
> altogether, working directly with objects which they should represent
> (which is far from the universal CA philosophy).
There might be some other avenues available as well. Tim Sheard
at OGI has been experimenting with 'staged' programming in his
MetaML system. In 'staged' programming, evaluation of a term is
delayed until the next 'stage' of program execution. His emphasis
has been on compilers and interpreters, but it struck me that
perhaps one could view symbolic evaluation as 'staging'? (of
course, I could be talking nonsense). Someone else (I'm afraid I
forget who..) was also working on something very similar, so the
'staging' idea is obviously timely.
> What really matters here is
>
> 1. A huge, huge library of algorithms. Rewriting Maple is a horrendal
> task. Making some toy system with limited functionality is aimless.
OK, but if the kernel of a system is available, then this task simply
depends on how much resource you are willing to allocate to it.
Obviously, it is a huge task though.
> 2. Nice graphical interfacing.
>
I dont think that one should rewrite the entire graphics system of
Mathematica or Maple! Surely the thing to do would be to use
HDirect and link to an existing graphics back end.
> There *is* a free Maple-like system: MuPAD from Paderborn, Germany. It
> is semantically more powerful than Maple, object-oriented (a little
> bit in the style of Python), but less functional - new Maple has at
> least closures, the binding protocol of MuPad is dynamic and obscure.
>
> Manufacturing it was so tiresome, that finally Benno Fuchssteiner
> decided to commercialize it, keeping still the free version, open
> for everybody. (I see some small analogies with Clean project, don't
> you?...)
>
> There *are* free clones of Matlab: RLab, SciLab, Octave, Tela.
>
> There is one *absolutely essential* requirement for the implementation
> of the kernel of such systems: VERY EFFICIENT array processing, with
> vectorized interface, slicing, sparse matrices handled efficiently,
> etc. Haskell has - it seems - still quite a mileage to go in this
> direction.
>
> The visual, dataflow style programming systems like LabView, Khoros,
> WiT,
> etc. -- hmmmm. this is one of my dreams, to do a thing like that. To,
> say, transform a Fudget-like package into a genuine development system
> for a functional language, with blocks linked together with data paths
> (and joyful Monads implementing these chains), with a lot of simulation-
> oriented blocks: signal generators, filters, image processors, etc.
>
> But is this dataflow style really compatible with canonical FP? I don't
> really know. I have seen the thesis of Hideki John Reekie (and another
> one, farther from FP, of Choi). If you know anything about the
> functional
> approach to dataflow, please let me know.
Visual programming sounds nice, but in practice it is of limited
use. If you have a smallish number of modules to link together, you
could do this as easily by hand-coding. If you have a larger number
of modules, you probably ought to think about simplifying the
system!
Rob MacAulay
Rob MacAulay
Cambridge
