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 QAA25311 for caml-redistribution; Wed, 6 Oct 1999 16:20:32 +0200 (MET DST) 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 JAA09845 for ; Wed, 6 Oct 1999 09:28:35 +0200 (MET DST) Received: from ruby (pm1-25.triode.net.au [203.63.235.41]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id JAA00931 for ; Wed, 6 Oct 1999 09:28:31 +0200 (MET DST) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by ruby (8.9.3/8.9.3) with ESMTP id UAA01570; Wed, 6 Oct 1999 20:17:24 +1000 Sender: weis Message-ID: <37FB21B4.43707397@maxtal.com.au> Date: Wed, 06 Oct 1999 20:17:24 +1000 From: skaller Organization: Maxtal P/L X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: Lyn A Headley CC: caml-list@inria.fr Subject: Re: Can someone explain? References: <19991005214250.7E194198@yeenoghu.cs.uchicago.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lyn A Headley wrote: > Here's an idea: just hijack the Python implementation and provide an > ocaml interface. This has the advantages that (1) it has been > hand-tuned for efficiency for years and (2) that it will export a > similar interface to the ocaml code as has existed for the C code for > years, thus allowing a smoother transition to ocaml for python > extension writers. I thought of that, and I was tempted! However, I decided against it for several reasons. First, while it leverages the Python code, it creates a headache for memory management, since Python does it's own, which doesn't sit well with ocaml garbage collector. Second, it means any extensions I wish to write will have to be written in C. This defeats the advantages of using ocaml. For example, I have already added a Rational type using the num module: I did it in only a few hours, and added long integers at the same time: the num long integers are already faster than the python ones. Third, it becomes sensitive to the C implementation of Python which changes with versions, and depends on the whims of developers who may have different goals than I do. > Come to think of it, why not do that for /all/ the builtin types? > These will also be useful for use by code generated by viperc. So will the ocaml based run time, if the compiler back end generates ocaml :-) There are two versions of Python: CPython (C) and JPython (Java). Both suffer from portability problems, due to the base language, compared with ocaml (IMHO). Both suffer from inferior technology, compared with ocaml (IMHO). My plan is to suport _pure_ python, not C based extensions: just the same as JPython cannot use C based extensions. I suspect that the C -> ocaml -> python wrapper chain for extensions representing external interfaces (operating system services and access to C libraries) is probably easier than the C -> CPython extension -> Python. However, a lot of C modules in python are only for efficiency, and it is better to rewrite these in Python and use the compiler, or, in ocaml if really necessary. > Darn it, now you've got > me all psyched about ocaml again. Too bad I already committed to > Eiffel for my latest project. Oh well :-) > An ocaml "port" of STL would kick ass. The code I showed is part of a set of modules I'm developing that (attempt to) provide ocaml representations of the same ideas. However, this has a lower priority than the python compiler. >especially, think how well > iterators would combine with closures! The C++ notion of "function > objects" and "adaptors" looks clumsy in comparison (e.g. you cannot > create a localized class object) Yes. In fact, I have a contract to write a book on STL, but I gave up precisely because of this. I tried to tell the committee, but they just didn't understand. STL isn't that useful in C++, because the core language fails to support nested functions, when it could. Furthermore, the committee broke the way unions work, so that they cannot be used to implement variants easily. I prefer to work with a language whose developers actually know some mathematics. > skaller> A class is used here to represent the whole list. It is > skaller> an object simply because that is the intended use: as a > skaller> mutable object with various mutators. In retrospect, this > skaller> is probably a mistake. > > why? Because, the functional operations, such as concatenation, require access to the private data, and cannot get it. There are no friends in ocaml: the correct solution is to abandon the class and use an algebraic data structure, and restrict the interface of the module so it becomes abstract. There is another reason: class methods cannot be polymorphic, wheres plain functions of modules can be (independently of instantiation of type parameters of the module). -- John Skaller, mailto:skaller@maxtal.com.au 1/10 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller downloads: http://www.triode.net.au/~skaller