Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Generics & a working mathematician's testimonial
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: S. Loisel <loisel@m...>
Subject: [Caml-list] Generics & a working mathematician's testimonial
Dear Bedouins,

Recently, there have been encouraging rumours[1] to the effect that 
"extensional polymorphism" would get more love. I am writing this to 
share with you my enthusiasm regarding this kind of polymorphism.

My current work is in scientific computing (solving PDE's and that kind 
of stuff) and, in a previous life, I worked in pure math in analysis, 
with computer proofs. As has been hinted by others[2,4,5,6], many in the 
scientific computing community (including adjacent disciplines such as 
weather simulation and such) are moving to C++ (while still using 
primarily Fortran) with a large contingent of people content to use Matlab.

For this community, it is very important to be able to write complicated 
mathematical expressions in a simple, legible fashion. It is also 
relatively important to be able to control the underlying number 
representations. Most applications use 64-bit floating point numbers, 
but some use 96 bits, and a small number of application are content to 
use 32 bit floating point. In addition, some applications need to use 
real numbers, and other applications need to use complex numbers, and a 
few applications need to use stranger scalar types. Some applications 
require interval arithmetic, while most people wouldn't be willing to 
carry that overhead. The cartesian product of all these is large.

The most important application is, of course, in linear algebra, where 
it is important to be able to manipulate vectors, matrices, and, in some 
cases, higher-order tensors with some elegance.

Fortran is clearly the incumbant, and in a way it does everything less 
well than the languages which are vying against it in the modern 
numerical laboratory. At the moment, Matlab, with its extremely large 
library of "toolboxes" and very efficient algorithms, is widely 
considered to be the tool that is easiest to use, and at the same time 
able to produce results that are important in the real world. Of course, 
from a language theorist's perspective, the Matlab language is brain 
damaged, in addition to its interpreter being hopelessly slow.

The appeal of C++ is obvious. To most of us, the polymorphism available 
in C++ is far greater than what is available in all other alternatives. 
And while it is not possible to define new operators, the overloading 
capabilities combined with the ample variety of existing operators to 
pick from make this language a self-evident choice when we wish to write 
  mathematical expressions and programs in a clear way.

I for one believe it is easier to write erroneous C++ code, compared to 
(say) g'caml. The primary culprit is C++'s lack of garbage collection, 
but sometimes I think that C++'s somewhat lax automatic type conversion 
plays a complicit role.

Many of my predecessors of the eighties held high hopes for Lisp, but us 
younguns prefer to be able to write mathematical expressions with infix 
operators, thank you very much. I also think that "overloading" wouldn't 
work very well in a dynamically typed language. Lastly, most of us 
aren't willing to pay for language features in performance, and dynamic 
typing can exact a toll (unless you go back and add typing hints with 
your profiler...)

In summary, to the community that I am most familiar with, genericity is 
a showstopper. A language such as g'caml would be welcome (at least by 
myself) with open arms as the promised saviour. However, it is with 
great sadness that I had to abandon previous work with ocaml, because 
all my operators were three characters long and the expressions had 
stopped making sense. There are issues, aside from genericity, which are 
  suboptimal for my community[3], but in the interest of staying 
focused, I will not discuss them.

I would invite relevant individuals to comment on their idea of what's 
in the future for such features, and I would like to thanks Jun Furuse 
for the very useful prototype that is g'caml.

Sincerely yours,

Sébastien Loisel

Notes:
[1] http://caml.inria.fr/archives/200305/msg00059.html
[2] e.g., http://caml.inria.fr/archives/200305/msg00205.html
[3] I know a lot of people who use SMP and NUMA, unlike what Xavier 
Leroy suggests here: http://caml.inria.fr/archives/200211/msg00274.html
[4] http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html
[5] 
http://www.codesourcery.com/pooma/pooma_publications/how_templates_enable_high_performance_scientific_computing_in_cplusplus
  This link should have no spaces. If some mail agent breaks up the 
line, you might have to rearrange it manually.
[6] I personally use mainly C++, and so does S. W. Drury (my advisor for 
the master's thesis, http://www.math.mcgill.ca/drury/.)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners