From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id FAA03151; Tue, 3 Jun 2003 05:51:33 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA02855 for ; Tue, 3 Jun 2003 05:51:32 +0200 (MET DST) Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h533pVT20955 for ; Tue, 3 Jun 2003 05:51:31 +0200 (MET DST) Received: from math.mcgill.ca ([24.202.74.221]) by VL-MS-MR002.sc1.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HFW001ZN01UTZ@VL-MS-MR002.sc1.videotron.ca> for caml-list@inria.fr; Mon, 02 Jun 2003 23:51:30 -0400 (EDT) Date: Mon, 02 Jun 2003 23:50:57 -0400 From: "S. Loisel" Subject: [Caml-list] Generics & a working mathematician's testimonial To: caml-list@inria.fr Message-id: <3EDC1B21.8020403@math.mcgill.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Spam: no; 0.00; generics:01 testimonial:99 extensional:01 matlab:01 scalar:01 vectors:01 higher-order:01 damaged:99 self-evident:01 g'caml:01 culprit:01 dynamically:01 lastly:01 toll:99 genericity:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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