From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA02436 for caml-red; Fri, 26 Jan 2001 22:04:18 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA19681 for ; Thu, 25 Jan 2001 13:03:44 +0100 (MET) Received: from info.numeric-quest.com (info.numeric-quest.com [204.187.76.36]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id f0PC3fL10995 for ; Thu, 25 Jan 2001 13:03:42 +0100 (MET) Received: (qmail 10112 invoked by uid 500); 25 Jan 2001 07:21:47 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Jan 2001 07:21:47 -0000 Date: Thu, 25 Jan 2001 02:21:47 -0500 (EST) From: Jan Skibinski To: Markus Mottl cc: OCAML Subject: Re: Announcement: LACAML In-Reply-To: <20010125011143.A11727@miss.wu-wien.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis@pauillac.inria.fr Markus, > Adding further functionality to this library by following the > implementation of the other functions is not difficult either (thanks > to the bigarrays), but it still requires some work, because the > FORTRAN-function interfaces are usually very fat: they often take more > than 10 arguments. This means writing a lot of error checking code if > one wants to handle all errors in OCaml - the default error handling > of these libraries is probably not advisable, because it aborts program > execution... When writing Eiffel interface (*) to C version of NAG library (similar to LAPACK, including BLAS, but commercial), several years ago, we had two basic problems to solve: 1. argument obesity (a Fortran legacy), as you mentioned it above 2. pointers to functions as arguments to other functions The first was easy to handle in the object oriented language: create an object with some defaults and provide auxiliary methods to change those defaults if needed. Another words, break those long chains of arguments into shorter pieces. It worked very well, but obviously required a lot of (exciting) engineering. But the result was stunningly clear, consise and easy to understand even by the beginners. I do not know whether similar approach would be feasible with Ocaml objects, but if yes then I would recommend it highly. The second problem was awkward to tackle in Eiffel, but this is where Ocaml will shine with its higher order functions. > * To make things easy for people used to the "real" implementation > in FORTRAN but also for beginners who need detailed documentation, > both function- and argument names have been kept compatible to the > ones used in the BLAS- and LAPACK-documentation. I do not see a need for this. The names are probably as awkward as in NAG. Just consistently refer to the original names in your documentation and you should be fine. Jan (*) This was EiffelMath for ISE Eiffel. ISE = Interactive Software Engineering, Santa Barbara, California