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.
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).
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.
2. Nice graphical interfacing.
(All this applies also to Matlab).
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.
Jerzy Karczmarczuk,
Caen, France
